Subject: Re: proposed fix for pthread_kill() of a zombie thread.
To: Chuck Silvers <firstname.lastname@example.org>
From: Nathan J. Williams <email@example.com>
Date: 10/09/2005 14:54:50
Chuck Silvers <firstname.lastname@example.org> writes:
> On Sun, Oct 09, 2005 at 02:07:35PM -0400, Nathan J. Williams wrote:
> > Looks good to me. I bet there are a couple of other places that don't
> > correctly handly PT_STATE_ZOMBIE... pthread_suspend_np() looks
> > problematic, for example.
> yup. what error should pthread_suspend_np() return in this case?
I'm not sure. This could be considered a no-op, like suspending an
already-suspended thread, or it could return EINVAL, to signal that
it doesn't make sense to suspend this thread.
> I see that pthread_suspend_np() and pthread_resume_np() also don't
> call pthread__find() to verify that the given pthread_t is valid like
> many of the other interface functions do, should they? neither does
Calling pthread__find() isn't needed all of the time. It exists for
functions that are guaranteed by the standard to return ESRCH when the
passed-in pthread_t value is bogus. For functions that are not so
constrained by the standard, it's fine to follow the
garbage-in-garbage-out principle, and let them segfault if someone
passes in (pthread_t)31337 or the pthread_t ID of an already-joined
thread. The pthread_suspend_np() function probably doesn't need this
level of safety.