Looks good to me. It might be useful to add that the hythread_t handle is no longer valid after the thread is completely detached. Our implementation supports recursive attaches, so the thread isn't completely detached until the detach count equals the attach count.
My main concern was to get this limitation documented before anyone violates it. Thanks, Angela On 6/21/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
Angela Lin wrote: > I suspect there was an attempt to cut down on calls to > pthread_getspecific() because it was showing up hot in some > benchmarks. Now, I don't know if detach() itself was also hot, but, > in our usage, we frequently already had the hythread_t available so it > probably seemed like a good idea to pass it in and circumvent the > gratuitous lookup. So how about a comment like this... /** * Detaches the current thread from the threading library. * * Detach must only be called by an attached thread. The actual parameter * must be the the current thread's hythread_t, or NULL (in which case this * function retrieves and uses the current thread's hythread_t). This * function cannot be used to detach an arbitrary thread. * * When detached, internal resources associated with the thread are freed. * * @param[in] thread * the hythread_t of the current thread to be detached, or NULL * meaning the current thread struct is looked-up and detached. * @return none * * @see hythread_attach */ Regards, Tim
