[RFC] Implement pthread_getthreadid_np(3) and pthread_getunique_np(3)

[Kostik Belousov]

On Mon, Feb 07, 2011 at 01:31:42PM -0500, Jung-uk Kim wrote:
> On Saturday 05 February 2011 04:58 am, Kostik Belousov wrote:
> > On Sat, Feb 05, 2011 at 02:24:09AM -0500, Jung-uk Kim wrote:
> > > On Friday 04 February 2011 04:33 pm, Kostik Belousov wrote:
> > > > On Fri, Feb 04, 2011 at 02:09:10PM -0500, Jung-uk Kim wrote:
> > > > > Our pthread_t is not an integral type and it causes a lot of
> > > > > trouble porting some software, which relies on Linux's
> > > > > gettid() or similar syscalls:
> > > > >
> > > > > http://www.kernel.org/doc/man-pages/online/pages/man2/gettid.
> > > > >2.ht ml
> > > > >
> > > > > For example:
> > > > >
> > > > > http://docs.freebsd.org/cgi/mid.cgi?201102032111.13479.jkim
> > > > >
> > > > > To solve this problem, I implemented two functions:
> > > > >
> > > > > http://people.freebsd.org/~jkim/thr_tid.diff
> > > > >
> > > > > Basically, they are AIX's pthread_getthreadid_np(3) and
> > > > > pthread_getunique_np(3) look-alikes:
> > > > >
> > > > > http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/a
> > > > >pis/ users_22.htm
> > > > > http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/a
> > > > >pis/ users_23.htm
> > > > >
> > > > > Please let me know what you think.
> > > >
> > > > Why do you need new functions available in stubs ?
> > >
> > > Oops, my bad.  Fixed:
> > >
> > > http://people.freebsd.org/~jkim/thr_tid2.diff
> > >
> > > > Also, would it be better to return proper id even if threading
> > > > is not initialized, instead of EINVAL  ?
> > >
> > > Because I want it to be fast and cause no side-effect, no.
> >
> > You can allocate static lwpid_t self_tid variable, and in case
> > threading is not initialized yet, and self_tid == 0, do
> > self_tid = thr_self(). Otherwise, if threading is initialized and
> > self_tid != 0, return self_tid.
> >
> > BTW, what should be the behaviour of new functions after fork() ?
> > Is it undefined ?
> 
> Please ignore this RFC.  I found (undocumented) thr_self(2) works just 
> like pthread_getthreadid_np(3) and I don't have immediate need for 
> pthread_getunique_np(3).
I think that making thr_* private libthr syscalls part of the
public namespace was unfortunate. If you need the functionality of
pthread_getthreadid_np(3), then please introduce it, as discussed above,
and use.

We already have somewhat sad experience with kse, when static binaries
where broken. Using thr_self() directly in such important application
as jdk/jre might cause similar problem in future (I hope not).

Also, you said that pthread_getthreadid_np(3) was taken from AIX, am I
remember right ? This is additional argument for use it instead of
single-implementation interface.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20110207/17a93240/attachment.pgp