<pthread.h> includes

[Bruce Evans]

On Sat, 20 Aug 2005, Stefan Farfeleder wrote:

> On Sat, Aug 20, 2005 at 03:48:31PM +1000, Bruce Evans wrote:
>> On Fri, 19 Aug 2005, Stefan Farfeleder wrote:
>>
>>> On Sat, Aug 20, 2005 at 12:04:56AM +1000, Bruce Evans wrote:
>>>> <sys/time.h>		only used to declare sigset_t and struct timespec.
>>>> 			We have a whole header, <sys/_sigset.h>, to help
>>>> 			declare sigset_t better (it only declares
>>>> 			__sigset_t),
>>> ...
>>> I've include <machine/_types.h> (for __uint32_t) and <sys/_sigset.h>
>>> instead.  timespec is declared through <time.h>.
>>
>> Too bad.
>
> Do you have a better suggestion?

No.  It's too late to change POSIX.

>>>> <sys/signal.h>		Just namespace pollution.
>>>
>>> We need MINSIGSTKSZ from <machine/signal.h> though.  The patch includes
>>> that header instead and protects its usage with __XSI_VISIBLE.  I'm not
>>> happy with this, maybe MINSIGSTKSZ should be moved somewhere else?
>>
>> MINSIGSTKSZ is used to define PTHREAD_STACK_MIN.  I didn't notice this
>> partly because the old version that I looked at correctly defiens
>> PTHREAD_STACK_MIN as a constant.  Everything is wrong here:
>> - POSIX requires PTHREAD_STACK_MIN to be defined (if at all) in
>>   <limits.h> but not in <pthread.h>.
>> - PTHREAD_STACK_MIN must be defined as a number (if at all even if
>>   XSI is no visible.
>
> I agree that <limits.h> is missing the
> PTHREAD_{DESTRUCTOR_ITERATIONS,KEYS_MAX,STACK_MIN,THREADS_MAX} macros.
> It's not an error for <pthread.h> to define them because POSIX
> reserves pthread_* and PTHREAD_* for this header.

I's not useful either, since non-broken applications still need to include
<limits.h> (or use sysconf()).

> I'm not sure why MINSIGSTKSZ (which expands to const * 4 on all
> architectures) is not a constant.

It's fairly machine-dependent.  const * 8 would make more sense on the
64-bit arches but the const is not always the same even with that scaling.
>
> What do you think about putting __MINSIGSTKSZ in <machine/_limits.h>?

OK.

>>>> <limits.h>		Just namespace pollution.
>>>
>>> <machine/_limits.h> is included instead and __ULONG_MAX is used.
>>
>> __ULONG_MAX is used to define PTHREAD_THREADS_MAX.  POSIX actually requires
>> the latter to be defined (if at all) in <limits.h> only too.  I doubt
>> that the limit is actually 2^64-1.  Maybe it should be a runtime limit
>> _SC_THREAD* are missing, so apparently no one ever asks for the runtime
>> limits.
>
> Which _SC_THREAD* is missing?  Calling sysconf() with
> _SC_THREAD_THREADS_MAX is buggy because sysconf converts ULONG_MAX to a
> long.

Er, none.  I grepped the wrong headers (only <sys>, but _SC_THREAD* is
in <unistd.h> and sysconf(3) on _SC_THREAD* never reaches the kernel).

Bruce