Re: pthread_t and thrd_t
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
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
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
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 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
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
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
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
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
pthread_t and thrd_t
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