Re: pthread_t and thrd_t

[Shware Systems]

It says that, yes, but above that it is explicit about which interfaces go into 
which libraries. That these libs as separate non-file entities may be searched 
when specified does not, to me, imply they can be combined and still be 
considered conforming. This goes to which namespaces each library takes from, 
where an application that has its own pthread_join() doesn't want an -l c 
before pthread_join.c on a command lineusing a version stored in the libc, 
whether -l pthread follows or not.

On Thursday, April 18, 2019 Joel Sherrill  wrote:


Thanks for quoting that. But just to be pedantic, it says "unspecified"
and "may"
so it is guidance.

The RTEMS' GCC (and llvm) configuration implicitly links in libc, the
BSP library,
and the all RTEMS services including things in libpthread or librt on
Linux. libm
is the only common library that a user would need to specify.  The flag
-pthread
is accepted by the compiler.

FWIW RTEMS is a single process POSIX environment with ~1100 of the POSIX
APIs.
The OS and application are one executable. We track POSIX APIs provided
versus
multiple versions of POSIX, PSE5x, C99 and C11, FACE TS 2.1 and 3.0, and
multiple
versions of SCA as part of our user facing documentation.

--joel


On 4/18/2019 10:54 AM, enh wrote:
> i think the requirement is only that the compiler accept -lpthread...
>
> "It is unspecified whether the libraries libc.a, libl.a, libm.a,
> libpthread.a, librt.a, [OB] [Option Start] libtrace.a, [Option End]
> libxnet.a, or liby.a exist as regular files. The implementation may
> accept as -l option-arguments names of objects that do not exist as
> regular files."
>
> Android has libpthread and librt in libc (though sadly libm is still 
> separate).
>
> On Thu, Apr 18, 2019 at 8:46 AM Joel Sherrill  
> wrote:
>>
>>
>> On 4/18/2019 4:31 AM, Geoff Clare wrote:
>>> Shware Systems  wrote, on 17 Apr 2019:
 On Wednesday, April 17, 2019 Geoff Clare  wrote:

> ... does anyone know of an implementation
> that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined
> as different types?
 My implementation defines both as pointers, not int's, as 'typedef
 thrd_t pthread_t;'. Since threads.h is 99% a subset of pthreads.h,
 I see no reason to have them be different types, even as a breaking
 change. What is missing is in pthreads.h, to account for the new
 attributes C11 introduced, at least to mention them if support
 isn't going to be added.
>>> What new attributes?  As far as I can see the only attribute a
>>> thread has in C17 (although it doesn't use that word) is whether it
>>> has been detached.
>>>
 The major hassle I see is POSIX wants the
 the threading stuff in libpthread, and C11 wants it in libc if the
 threading option is enabled. IMO C11 should have let interfaces in
 optional headers all be in header-specific libraries or libc, as an
 implentation-defined choice, but they didn't.
>>> Last I knew the C standard says nothing at all about how programs
>>> are built.
>> Is there even a requirement to have libpthread in POSIX?
>>
>> --joel
>>

Re: pthread_t and thrd_t

[Joel Sherrill]

Thanks for quoting that. But just to be pedantic, it says "unspecified" 
and "may"
so it is guidance.

The RTEMS' GCC (and llvm) configuration implicitly links in libc, the 
BSP library,
and the all RTEMS services including things in libpthread or librt on 
Linux. libm
is the only common library that a user would need to specify.  The flag 
-pthread
is accepted by the compiler.

FWIW RTEMS is a single process POSIX environment with ~1100 of the POSIX 
APIs.
The OS and application are one executable. We track POSIX APIs provided 
versus
multiple versions of POSIX, PSE5x, C99 and C11, FACE TS 2.1 and 3.0, and 
multiple
versions of SCA as part of our user facing documentation.

--joel

On 4/18/2019 10:54 AM, enh wrote:
> i think the requirement is only that the compiler accept -lpthread...
>
> "It is unspecified whether the libraries libc.a, libl.a, libm.a,
> libpthread.a, librt.a, [OB] [Option Start] libtrace.a, [Option End]
> libxnet.a, or liby.a exist as regular files. The implementation may
> accept as -l option-arguments names of objects that do not exist as
> regular files."
>
> Android has libpthread and librt in libc (though sadly libm is still 
> separate).
>
> On Thu, Apr 18, 2019 at 8:46 AM Joel Sherrill  
> wrote:
>>
>>
>> On 4/18/2019 4:31 AM, Geoff Clare wrote:
>>> Shware Systems  wrote, on 17 Apr 2019:
 On Wednesday, April 17, 2019 Geoff Clare  wrote:

> ... does anyone know of an implementation
> that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined
> as different types?
 My implementation defines both as pointers, not int's, as 'typedef
 thrd_t pthread_t;'. Since threads.h is 99% a subset of pthreads.h,
 I see no reason to have them be different types, even as a breaking
 change. What is missing is in pthreads.h, to account for the new
 attributes C11 introduced, at least to mention them if support
 isn't going to be added.
>>> What new attributes?  As far as I can see the only attribute a
>>> thread has in C17 (although it doesn't use that word) is whether it
>>> has been detached.
>>>
 The major hassle I see is POSIX wants the
 the threading stuff in libpthread, and C11 wants it in libc if the
 threading option is enabled. IMO C11 should have let interfaces in
 optional headers all be in header-specific libraries or libc, as an
 implentation-defined choice, but they didn't.
>>> Last I knew the C standard says nothing at all about how programs
>>> are built.
>> Is there even a requirement to have libpthread in POSIX?
>>
>> --joel
>>

Re: pthread_t and thrd_t

[enh]

i think the requirement is only that the compiler accept -lpthread...

"It is unspecified whether the libraries libc.a, libl.a, libm.a,
libpthread.a, librt.a, [OB] [Option Start] libtrace.a, [Option End]
libxnet.a, or liby.a exist as regular files. The implementation may
accept as -l option-arguments names of objects that do not exist as
regular files."

Android has libpthread and librt in libc (though sadly libm is still separate).

On Thu, Apr 18, 2019 at 8:46 AM Joel Sherrill  wrote:
>
>
>
> On 4/18/2019 4:31 AM, Geoff Clare wrote:
> > Shware Systems  wrote, on 17 Apr 2019:
> >> On Wednesday, April 17, 2019 Geoff Clare  wrote:
> >>
> >>> ... does anyone know of an implementation
> >>> that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined
> >>> as different types?
> >> My implementation defines both as pointers, not int's, as 'typedef
> >> thrd_t pthread_t;'. Since threads.h is 99% a subset of pthreads.h,
> >> I see no reason to have them be different types, even as a breaking
> >> change. What is missing is in pthreads.h, to account for the new
> >> attributes C11 introduced, at least to mention them if support
> >> isn't going to be added.
> > What new attributes?  As far as I can see the only attribute a
> > thread has in C17 (although it doesn't use that word) is whether it
> > has been detached.
> >
> >> The major hassle I see is POSIX wants the
> >> the threading stuff in libpthread, and C11 wants it in libc if the
> >> threading option is enabled. IMO C11 should have let interfaces in
> >> optional headers all be in header-specific libraries or libc, as an
> >> implentation-defined choice, but they didn't.
> > Last I knew the C standard says nothing at all about how programs
> > are built.
>
> Is there even a requirement to have libpthread in POSIX?
>
> --joel
>

Re: pthread_t and thrd_t

[Joel Sherrill]

On 4/18/2019 4:31 AM, Geoff Clare wrote:
> Shware Systems  wrote, on 17 Apr 2019:
>> On Wednesday, April 17, 2019 Geoff Clare  wrote:
>>
>>> ... does anyone know of an implementation
>>> that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined
>>> as different types?
>> My implementation defines both as pointers, not int's, as 'typedef
>> thrd_t pthread_t;'. Since threads.h is 99% a subset of pthreads.h,
>> I see no reason to have them be different types, even as a breaking
>> change. What is missing is in pthreads.h, to account for the new
>> attributes C11 introduced, at least to mention them if support
>> isn't going to be added.
> What new attributes?  As far as I can see the only attribute a
> thread has in C17 (although it doesn't use that word) is whether it
> has been detached.
>
>> The major hassle I see is POSIX wants the
>> the threading stuff in libpthread, and C11 wants it in libc if the
>> threading option is enabled. IMO C11 should have let interfaces in
>> optional headers all be in header-specific libraries or libc, as an
>> implentation-defined choice, but they didn't.
> Last I knew the C standard says nothing at all about how programs
> are built.

Is there even a requirement to have libpthread in POSIX?

--joel

Re: pthread_t and thrd_t

[Geoff Clare]

Geoff Clare  wrote, on 17 Apr 2019:
>
> ... does anyone know of an implementation
> that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined
> as different types?

My thanks to the people who replied.  So it seems there are several
implementations now that all have pthread_t and thrd_t as the same
type, and nobody has (yet) identified one that doesn't.

This is good (in a way) but leads to some complications as to how
the standard should specify the relationship between thread IDs with
different origins.  If they are required to be the same type, the
question arises as to whether they should be completely
interchangeable.  The answer to that is no, because the thread exit
status is different (for pthreads it is void *; for C11/C17 threads
it is int).  This means we will have to say that the behaviour is
undefined if pthread_join() is called for a thread created using
thrd_create() or thrd_join() is called for a thread created using
pthread_create() or via a SIGEV_THREAD notification, and is undefined
if pthread_exit() is called in a thread created using thrd_create()
or thrd_exit() is called in a thread created using pthread_create() or
via a SIGEV_THREAD notification.  But it gets worse: what about the
initial thread?

POSIX and C17 allow pthread_exit() and thrd_exit(), respectively, to
be called from the initial thread, and it looks like there is nothing
in C17 to forbid calling thrd_join() on the initial thread (it says
"The thread identified by thr shall not have been previously detached
or joined with another thread" and this condition is true for the
initial thread), although it's not clear to me whether in POSIX the
initial thread is required to be joinable.  Anyway, thrd_join() alone
is enough of a problem: are we really going to have to say that if
thrd_join() is called on the initial thread and that thread terminates
(or has terminated) by calling pthread_exit(), the behaviour is
undefined?

Another complication is cancellation.  If pthread_cancel() is called
for a thread that was created using thrd_create(), then that's a
problem because thrd_join() has no way to indicate that the thread
was cancelled.  We can't reserve an exit status value for it, because
conforming C17 programs are entitled to use the full [INT_MIN,INT_MAX]
range of exit status values.  I would be nervous about adding a
thrd_canceled enumerator because that might be seen as trespassing on
an area that "belongs" to the C committee.  (I suppose we could seek
their blessing for the addition.)  We may have to resort to another
statement about undefined behaviour.

Any suggestions?

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

Re: pthread_t and thrd_t

[Joel Sherrill]

On 4/17/2019 3:53 PM, Alan Coopersmith wrote:
> On 4/17/19 8:58 AM, Geoff Clare wrote:
>> So glibc will conform if we require that pthread_t and thrd_t are
>> defined as the same type, but does anyone know of an implementation
>> that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined
>> as different types?
> Not here, Oracle Solaris 11.4 has the same type for both:
>
> /usr/include/sys/types.h:
> typedef unsigned intuint_t;
> typedefuint_t  pthread_t;  /* = thread_t in thread.h */
>
> /usr/include/threads.h:
> typedef unsigned int thrd_t;
>
> To see the full headers for yourself:
>
> /usr/include/sys/types.h:
> curl -s 
> http://pkg.oracle.com/solaris/release/file/0/55ae99dec04f09e8fe9963d87d24ae371c8e85b9
>  | gzcat | less
>
> /usr/include/threads.h:
> curl -s 
> http://pkg.oracle.com/solaris/release/file/0/183228c541fb3e2b2b6c710fa46964d94ee259a8
>  | gzcat | less
>
> (For others, substitute the hash listed at the beginning of the line after
>   "file" for the given header file listed in
>   
> http://pkg.oracle.com/solaris/release/manifest/0/system%2Fheader@11.4%2C5.11-11.4.0.0.1.15.0%3A20180817T003001Z
>  )
>
RTEMS uses the Newlib C library like Cygwin. The C11 threads header is
from FreeBSD.  The RTEMS pthread_t and thrd_t both are defined to
uint32_t. Newlib's pthread.h, sys/_pthreadtypes.h, threads.h, and
machine/threads.h can be browsed here:

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libc/include;h=448a39cdb98eafe471a761e2fbfecf8dfa41fa31;hb=HEAD

RTEMS uses the FreeBSD implementation of these services and that's here:

https://git.rtems.org/rtems/tree/cpukit/libstdthreads

Also, for RTEMS, the C11 threads are not in libc, they are part of the RTEMS
threading services library.

--joel sherrill
RTEMS

Re: pthread_t and thrd_t

[Alan Coopersmith]

On 4/17/19 8:58 AM, Geoff Clare wrote:
> So glibc will conform if we require that pthread_t and thrd_t are
> defined as the same type, but does anyone know of an implementation
> that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined
> as different types?

Not here, Oracle Solaris 11.4 has the same type for both:

/usr/include/sys/types.h:
typedef unsigned intuint_t;
typedefuint_t  pthread_t;  /* = thread_t in thread.h */

/usr/include/threads.h:
typedef unsigned int thrd_t;

To see the full headers for yourself:

/usr/include/sys/types.h:
curl -s 
http://pkg.oracle.com/solaris/release/file/0/55ae99dec04f09e8fe9963d87d24ae371c8e85b9
 | gzcat | less

/usr/include/threads.h:
curl -s 
http://pkg.oracle.com/solaris/release/file/0/183228c541fb3e2b2b6c710fa46964d94ee259a8
 | gzcat | less

(For others, substitute the hash listed at the beginning of the line after 
 "file" for the given header file listed in
 
http://pkg.oracle.com/solaris/release/manifest/0/system%2Fheader@11.4%2C5.11-11.4.0.0.1.15.0%3A20180817T003001Z
 )

-- 
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc

Re: pthread_t and thrd_t

[enh]

for Android, i've been sitting this one out waiting for it to actually
matter (i wasn't aware glibc had added this API --- i thought musl was
the only implementation to date), but my intention is to just reuse
the pthread types, not least because that lets me offer this in a
backwards compatible way to old versions of Android that shipped
before this stuff gets added. (it's not in Android Q.)

looks like while i was sleeping FreeBSD implemented it too:
https://github.com/freebsd/freebsd/tree/master/lib/libstdthreads

/me wonders why no-one seems to have used pthread_key_t for tss_t,
even when they have reused the pthreads types for the other stuff...

On Wed, Apr 17, 2019 at 8:59 AM Geoff Clare  wrote:
>
> I'm working on drafting the changes to align POSIX with C17 and I
> have a question for the group about the types pthread_t and thrd_t.
>
> It seems to me that it would be best if these are defined as the
> same type, so that there are no complications with calling both
> pthread_self() and thrd_current() from:
>
> * The initial thread.
>
> * Threads created using pthread_create().
>
> * Threads created using thrd_create().
>
> * Threads created via a SIGEV_THREAD notification.
>
> If pthread_t and thrd_t were allowed to be different types, I
> suppose this could be made to work by giving the initial thread
> two IDs, one of each type, and forbidding calls to pthread_self()
> from threads created using thrd_create() or calls to thrd_current()
> from threads created using pthread_create() or via a SIGEV_THREAD
> notification.  However, this would be a nightmare for third-party
> libraries if they want to use pthread_self() or thrd_current() in
> a thread they don't create themselves.  (I suppose they would have
> to have two flavours of the library, one for pthreads and one for
> C11/C17 threads.)
>
> I had a look at the current glibc source, and was initially alarmed
> to see that it defines thrd_t as unsigned long int, since I was
> sure I could remember pthread_t being a structure pointer, but I
> see that it now has pthread_t as unsigned long int as well:
>
> https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/nptl/threads.h;hb=HEAD
>
> https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/nptl/bits/pthreadtypes.h;hb=HEAD
>
> So glibc will conform if we require that pthread_t and thrd_t are
> defined as the same type, but does anyone know of an implementation
> that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined
> as different types?
>
> --
> Geoff Clare 
> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
>

RE: pthread_t and thrd_t

[Shware Systems]

My implementation defines both as pointers, not int's, as 'typedef thrd_t 
pthread_t;'. Since threads.h is 99% a subset of pthreads.h, I see no reason to 
have them be different types, even as a breaking change. What is missing is in 
pthreads.h, to account for the new attributes C11 introduced, at least to 
mention them if support isn't going to be added.The major hassle I see is POSIX 
wants the the threading stuff in libpthread, and C11 wants it in libc if the 
threading option is enabled. IMO C11 should have let interfaces in optional 
headers all be in header-specific libraries or libc, as an implentation-defined 
choice, but they didn't. 

On Wednesday, April 17, 2019 Geoff Clare  wrote:

I'm working on drafting the changes to align POSIX with C17 and I
have a question for the group about the types pthread_t and thrd_t.

It seems to me that it would be best if these are defined as the
same type, so that there are no complications with calling both
pthread_self() and thrd_current() from:

* The initial thread.

* Threads created using pthread_create().

* Threads created using thrd_create().

* Threads created via a SIGEV_THREAD notification.

If pthread_t and thrd_t were allowed to be different types, I
suppose this could be made to work by giving the initial thread
two IDs, one of each type, and forbidding calls to pthread_self()
from threads created using thrd_create() or calls to thrd_current()
from threads created using pthread_create() or via a SIGEV_THREAD
notification.  However, this would be a nightmare for third-party
libraries if they want to use pthread_self() or thrd_current() in
a thread they don't create themselves.  (I suppose they would have
to have two flavours of the library, one for pthreads and one for
C11/C17 threads.)

I had a look at the current glibc source, and was initially alarmed
to see that it defines thrd_t as unsigned long int, since I was
sure I could remember pthread_t being a structure pointer, but I
see that it now has pthread_t as unsigned long int as well:

https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/nptl/threads.h;hb=HEAD

https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/nptl/bits/pthreadtypes.h;hb=HEAD

So glibc will conform if we require that pthread_t and thrd_t are
defined as the same type, but does anyone know of an implementation
that has pthreads and C11/C17 threads, with pthread_t and thrd_t defined
as different types?

--
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England