<pthread.h> includes

[Bruce Evans]

On Fri, 19 Aug 2005, Stefan Farfeleder wrote:

> On Sat, Aug 20, 2005 at 12:04:56AM +1000, Bruce Evans wrote:
>> On Fri, 19 Aug 2005, Stefan Farfeleder wrote:
>>
>>> I think some of the headers included by <pthread.h> violate the POSIX
>>> specification (I'm looking at SUSv3/POSIX 1003.1 2004) by making more
>>> symbols visible than allowed.
>>>
>>> <sys/cdefs.h>		Ok
>>> <sys/types.h>		Ok
>>> <sys/_pthreadtypes.h>	Ok
>>> <sys/time.h>		No? (POSIX allows <time.h> which is a subset)
> 				   ^^^^^^
> Actually POSIX kind of requires the inclusion of <time.h> (and
> <sched.h>).  At least all symbols must be visible.

Urk.  This seems to be the place in POSIX where namespace pollution is
explictly required.  According to an old draft:

%%%
10351           Inclusion of the <pthread.h> header shall make symbols defined in the headers <sched.h> and
10352           <time.h> visible.
%%%

Everywhere else, POSIX permits both broken and non-broken implementations
by saying "may make visible".

The history of this is interesting:

%%%
10408               IEEE PASC Interpretation 1003.1 #86 is applied, allowing the symbols from <sched.h> and
10409               <time.h> to be made visible when <pthread.h> is included. Previously this was an XSI
10410               extension.
%%%

The weasels who wrote "may" were apparently not present when this was
interpreted :-).

%%%
10411               IEEE PASC Interpretation 1003.1c #42 is applied, removing the requirement for prototypes for
10412               the pthread_kill ( ) and pthread_sigmask( ) functions. These are required to be in the <signal.h>
10413               header. They are allowed here through the name space rules.
%%%

sigset_t apparently isn't required here either.

>> <sys/cdefs.h>		needed, but can be obtained as a side effect
>> 			of including almost any other header in the list.
>> <sys/types.h>		only used to declare size_t.  We handle this better
>> 			in many other headers.  The old draft of POSIX that
>> 			I'm looking at doesn't say that <pthread.h> declares
>> 			size_t, so it might be conformant to use __size_t
>> 			in the prototypes.
>
> Removed, size_t is obtained via <time.h>.

OK.

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

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

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

>> <sched.h>		only used to declare struct sched_param and to
>> 			satisfy a POSIX mistake.  A forward declaration
>> 			would suffice.
>
> Left because POSIX says so.

Not too bad.

> The patch for <pthread.h> is at
> http://people.freebsd.org/~stefanf/pthread.h.diff .
>
> There are a few files that need <sys/types>, <limits.h>, etc symbols and
> get them by <pthread.h> inclusion, the patch at
> http://people.freebsd.org/~stefanf/pthread.h-2.diff fixes that.  It
> should probably be committed anyway.

An alarming number.  We shouldn't need so many new includes of
<sys/types.h>,

Bruce