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

[Jung-uk Kim]

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

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/apis/users_22.htm
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/users_23.htm

Please let me know what you think.

Thanks!

Jung-uk Kim
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threads
To unsubscribe, send any mail to "[hidden email]"

[Jung-uk Kim]

On Friday 04 February 2011 02:09 pm, 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.html
>
> 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

BTW, you can easily emulate semantic of Linux's gettid() with it:

#include <pthread_np.h>
#include <sys/types.h>
#include <unistd.h>

pid_t
gettid(void)
{

        if (pthread_main_np() == 0)
                return (pthread_getthreadid_np());
        return (getpid());
}

Jung-uk Kim
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threads
To unsubscribe, send any mail to "[hidden email]"

[Konstantin Belousov]

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.html
>
> 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/apis/users_22.htm
> http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/users_23.htm
>
> Please let me know what you think.

Why do you need new functions available in stubs ?

Also, would it be better to return proper id even if threading is not
initialized, instead of EINVAL  ?

[Jung-uk Kim]

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/apis/
> >users_22.htm
> > http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/
> >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.

Jung-uk Kim
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threads
To unsubscribe, send any mail to "[hidden email]"

[Konstantin Belousov]

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/apis/
> > >users_22.htm
> > > http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/
> > >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 ?

[Jung-uk Kim]

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

Thanks!

Jung-uk Kim
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threads
To unsubscribe, send any mail to "[hidden email]"

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

[Jung-uk Kim]

On Monday 07 February 2011 03:20 pm, Kostik Belousov wrote:

> 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/get
> > > > > >tid. 2.ht ml
> > > > > >
> > > > > > For example:
> > > > > >
> > > > > > http://docs.freebsd.org/cgi/mid.cgi?201102032111.13479.jk
> > > > > >im
> > > > > >
> > > > > > 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/top
> > > > > >ic/a pis/ users_22.htm
> > > > > > http://publib.boulder.ibm.com/infocenter/iseries/v5r4/top
> > > > > >ic/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.

Agreed.

http://people.freebsd.org/~jkim/thr_tid3.diff

Please note pthread_getunique_np() is removed.

Thanks,

Jung-uk Kim
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threads
To unsubscribe, send any mail to "[hidden email]"

[Konstantin Belousov]

On Mon, Feb 07, 2011 at 03:58:01PM -0500, Jung-uk Kim wrote:

> On Monday 07 February 2011 03:20 pm, Kostik Belousov wrote:
> > 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/get
> > > > > > >tid. 2.ht ml
> > > > > > >
> > > > > > > For example:
> > > > > > >
> > > > > > > http://docs.freebsd.org/cgi/mid.cgi?201102032111.13479.jk
> > > > > > >im
> > > > > > >
> > > > > > > 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/top
> > > > > > >ic/a pis/ users_22.htm
> > > > > > > http://publib.boulder.ibm.com/infocenter/iseries/v5r4/top
> > > > > > >ic/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.
>
> Agreed.
>
> http://people.freebsd.org/~jkim/thr_tid3.diff
>
> Please note pthread_getunique_np() is removed.

Looks good.