Date: Sat, 20 Aug 2005 20:57:39 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Stefan Farfeleder <stefanf@FreeBSD.org> Cc: threads@FreeBSD.org, standards@FreeBSD.org Subject: Re: <pthread.h> includes Message-ID: <20050820204228.T2739@epsplex.bde.org> In-Reply-To: <20050820081649.GA85488@wombat.fafoe.narf.at> References: <20050819093649.GU21905@wombat.fafoe.narf.at> <20050819231640.E2640@epsplex.bde.org> <20050819183507.GE77069@wombat.fafoe.narf.at> <20050820151252.L60332@delplex.bde.org> <20050820081649.GA85488@wombat.fafoe.narf.at>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050820204228.T2739>