apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: apr_threads.m4 patch for Solaris
Date Thu, 22 Feb 2001 17:02:17 GMT
> I wonder if sigwait() is the limit of our exposure.  In a separate
> thread I suggested something like this:
> >Or maybe in common code after the system-specific part of
> >apr_hints.m4...
> >
> >  if test "$enable_threads != "no"; then
> >    if test "x$THREAD_CPPFLAGS" != "x"; then # avoid adding blank :)
> >    fi
> >  fi
> >This assumes that we only hard-code THREAD_CPPFLAGS for platforms
> >which actually have threads.
> Now I see it should have been CPPFLAGS which we add THREAD_CPPFLAGS to
> here.
> This would seem to be more general, and lessen the ordering
> restrictions.
> (but I'm not real sure :) )

Yeah, I actually thought about this some more, and merely moving the
test around won't do much.  apr_sigwait will still be defined.  It
needs to be undefined when threads are not enabled.  sigwait is pretty
useless without threads.

In the general case though, the specific ordering of the tests frightens
me a bit.  I think Roy probably has some long-term ideas - but, either 
moving the test around or adding THREAD_CPPFLAGS to CPPFLAGS or (as you 
suggested) have these tests use THREAD_CPPFLAGS rather than CPPFLAGS will 
work in the short term.

The question becomes would adding THREADS_CPPFLAGS (by using a new autoconf
function) break any tests?  Unless you use per-file/per-dir CPPFLAGS when 
compiling (not really feasible since I believe that some OSes require every 
object to have _REENTRANT specified to maintain thread safety), all files will 
eventually be compiled with the options specified in THREADS_CPPFLAGS if 
threads are enabled.  So, maybe specifying CPPFLAGS to include 
THREADS_CPPFLAGS is the way to go.  Assume if threading is broken (HP-UX 
10.20 comes to mind), you'd want to back out that change ASAP.  Therefore, 
the test for threading should be done first (before the MM tests, perhaps?) 
- that way, if there are special defines required, all subsequent tests will 
have a chance to be tested with the "correct" CPPFLAGS set.

Interesting - the Solaris man page intro (3) indicates that either
defined.  Can we combine them?  They sound mutually exclusive.  Anyone know 
what the proper behavior is?

I have class all day today, so I won't be able to submit a patch to this
effect.  Sorry.

Justin Erenkrantz

View raw message