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.

> 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.

        - Nathan