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.
Regards, Angela On 6/21/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
Angela Lin wrote: > Hi folks, > > Could you take a peek at: > https://issues.apache.org/jira/browse/HARMONY-4237 > > Text: > The docs/comments for hythread_detach() and > HyThreadLibrary->thread_detach() should be amended to note the > limitation that these functions can only be used to detach the > _current_ thread (and not any arbitrary thread). > > Because these funcs accept a hythread_t parameter, this may not be obvious. > > This limitation exists because the implementation may use some thread > local storage. > > > It's not quite a bug. I think it's a limitation that was accidentally > omitted from our original document/spec for the hythread API. > > I hope you think this limitation is reasonable - it's > implementation-influenced, but I think other implementations might > want to use thread local storage too. So why does this function need the argument at all, especially since you can pass NULL to mean the current thread? i.e. when would you call this with anything other than MACRO_SELF() or NULL (which has the same effect). Regards, Tim
