Ben Harris <bjh21@netbsd.org> writes:

> >I'm also somewhat concerned that this exposes the symbols too widely,
> >since lots of other headers include <sys/types.h>.
> 
> All versions of POSIX and XPG permit any name ending in "_t" to be exposed
> by any header.  As such, as long as you wrap it in some kind of feature-test
> so that pure ANSI source doesn't see it, you should be fine.

OK, good to know.

> >Next, I was looking for a place to put PTHREAD_DESTRUCTOR_ITERATIONS
> >and PTHREAD_KEYS_MAX such that the values end up in <limits.h>, and
> >couldn't see a good spot of prior art for actual limit values, as
> >opposed to minimum values...?
> 
> First, are they ever going to vary?  If new versions of libpthread might
> have different values, you might like to leave them undefined and force
> applications to use sysconf().  That way, you don't have to bump the major
> version number of libpthread just because you changed a constant.

That's a good point. They might vary, or in the case of
PTHREAD_KEYS_MAX, become indefinite.

> I think you're confusing two types of _POSIX_* name.  Some of them (like
> _POSIX_PTHREAD_KEYS_MAX) define minimum limits and should appear in
> <limits.h>.  Others (like _POSIX_THREADS) indicate the presence of features,
> and should appear in <unistd.h>.

Hm. I was going from the text in the description of <limits.h> that
reads:

"Symbolic constant names beginning with _POSIX may be found in
<unistd.h>"

but that doesn't agree with the later statement further in the
<limits.h> page (which supports what you said):

"The symbolic constants in the following list shall be defined in
<limits.h> with the values shown."

So I'm not sure what the first statement is trying to say, but I'm
happy to not worry about it.

> >Finally, there are a bunch of pthread-related sysconf() variables
> >relating to feature-testing and limits. Is the correct approach to
> >define a CTL_USER sysctl for each _SC_* symbol and glue all the cases
> >into sysconf.c and sysctl.c in libc?
> 
> I'm not sure I have a clear opinion on this.  My preference would be to have
> a __pthread_sysconf() in libpthread that's used by sysconf() to get
> pthread-specific values.  That way, you always get the values appropriate
> the running libpthread.  CTL_USER seems like a horrible idea to me.

CTL_USER seems like a horrible idea to me, too, but essentially all of
sysconf() is implemented that way already. Calling into a routine in
libpthread is interesting in that there would also need to be a
version of the routine in libc to return a value to applications that
aren't linked with libpthread. I suppose it would be okay to return
the standard minimums to an application that doesn't have libpthread
linked in. I'm not sure whether feature flags should report present or
absent in that case, though.

This requires that the meaning of "current value" for the purposes of
sysconf(3) can be interpreted as "current for this process" rather
than "current for applications on this system in general"... which is
how _SC_CHILD_MAX and _SC_OPEN_MAX behave already, so that seems good.

        - Nathan