harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Angela Lin" <alin.harm...@gmail.com>
Subject Re: [portlib] hythread_detach limitation
Date Thu, 21 Jun 2007 21:42:30 GMT
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 <t.p.ellison@gmail.com> 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
>

Mime
View raw message