On Sun, Oct 09, 2005 at 02:54:50PM -0400, Nathan J. Williams wrote:
> Chuck Silvers <chuq@chuq.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.

-Chuck