On 16 Jul 2003, Nathan J. Williams wrote:

> "Symbolic constant names beginning with _POSIX may be found in
> <unistd.h>"
...
> So I'm not sure what the first statement is trying to say, but I'm
> happy to not worry about it.

I'm not sure what it's trying to say, either.  It's probably safe to
ignore 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.

<FX: checks> Ah, it's not quite as evil as I'd thought -- I hadn't
realised that CTL_USER was done in libc rather than the kernel.  This is
still slightly unfortunate given that it's libpthread rather than libc
that sets the values, though.

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

POSIX sysconf() requires that the values returned (except for {OPEN_MAX})
be constant over the life of the calling process.  It seems to be left
undefined whether they can vary between concurrent processes, and I can
just about imagine a situation where a process calls sysconf() to get a
value that it expects will apply to its children, where they're threaded
and it isn't.

As I said,I have few definite opinions here.  My current thoughts (which I
fully expect to be different tomorrow) are:

All applications should see sysconf(_SC_THREADS) > 0.  Applications which
aren't linked against libpthread can't actually call any pthreads
functions, but the system still supports threading.  The fact that
non-threaded applications can't dlopen() threaded libraries (is this still
true?) may complicate this, though.

It would be nice if all applications could get accurate values for
sysconf(_SC_THREAD_*) if those are generally constant between threaded
processes.  If they can't, I think that returning -1 (i.e. an indefinite
limit) would be more honest than returning an incorrect answer.

I think it's reasonable to expect people to upgrade libc and libpthread in
step, so I don't think there's anything inherently evil in having
compile-time constants from libpthread embedded in libc.

So my conclusion (if you can call it that) is that almost any way of
handling this is probably good enough, and I'd suggest doing whatever
seems easiest or cleanest.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/acorn26           <URL:http://www.netbsd.org/Ports/acorn26/>