Subject: Re: proposed fix for pthread_kill() of a zombie thread.
To: Nathan J. Williams <email@example.com>
From: Chuck Silvers <firstname.lastname@example.org>
Date: 10/09/2005 12:01:50
On Sun, Oct 09, 2005 at 02:54:50PM -0400, Nathan J. Williams wrote:
> Chuck Silvers <email@example.com> 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.
ok, I'll go for the no-op.
> > 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
> > pthread_cancel().
> 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.
ok. I guess pthread_suspend_np() isn't part of the standard?
at least, I couldn't find it at www.opengroup.org.
pthread_cancel() is supposed to do the ESRCH thing, I'll fix that.