Date: Sat, 20 Aug 2005 10:16:52 +0200 From: Stefan Farfeleder <stefanf@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: threads@FreeBSD.org, standards@FreeBSD.org Subject: Re: <pthread.h> includes Message-ID: <20050820081649.GA85488@wombat.fafoe.narf.at> In-Reply-To: <20050820151252.L60332@delplex.bde.org> References: <20050819093649.GU21905@wombat.fafoe.narf.at> <20050819231640.E2640@epsplex.bde.org> <20050819183507.GE77069@wombat.fafoe.narf.at> <20050820151252.L60332@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
> >>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.
> %%%
That's what I have here too.
[...]
> >>...
> >><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?
> >><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'm not sure why MINSIGSTKSZ (which expands to const * 4 on all
architectures) is not a constant.
What do you think about putting __MINSIGSTKSZ in <machine/_limits.h>?
> >><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.
Stefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050820081649.GA85488>