apache-nspr-04

[Dean Gaudet <dg...@arctic.org>]

http://www.arctic.org/~dgaudet/apache/2.0/apache-nspr-04.tar.gz

- remove all MULTITHREAD code, this could easily have been Sam's problem
with win32... it's replaced by NSPR.  Remove multithread.h.  The win32
makefiles probably all need updating.  They should define only WIN32, not
MULTITHREAD... and for now I'm not sure what to do with os/win32.  In
theory, until we want to add back in the features such as starting as a
service, and registry stuff, we don't want most of what was in there. 

- a few bug fixes

- revamped timeouts completely; some cleanup still to come... I think it's
a much simpler system now, and it even shows up as a little faster.  See
below for a snippet from the README.NSPR.  You know that ap_bonerror() 
function that's not used by anything currently?  It's finally used by
this.

It's really nice when a diff has more lines removed than added... while
improving functionality :) 

Dean

Timeouts:

    In Apache 1.x, developers have to be very careful about placement
    of hard/soft/kill_timeout function calls.  In particular, if they
    happen not to wrap a call to one of the BUFF routines they could do
    a network write w/o timeout.  Or if they accidentally invoke another
    module with a timeout in scope they could end up with resource leaks,
    or worse, crashes.  Timeouts also don't nest, so that the developer
    has to be careful to avoid calling routines that play with timeouts
    when a timeout is scope.

    A hard timeout has the disadvantage that 3rd party libraries may not
    take too well to longjmps (they have no way to register any sort of
    cleanup that could be necessary).  A soft timeout has the disadvantage
    that 3rd party libraries (and even libc) do not take kindly to EINTRs,
    generally because of poor coding.  It would be nice to avoid both.

    Apache 1.x timers on unix have the advantage that any operation
    can be aborted, even CPU intensive operations.  Apache 1.3 WIN32
    timers only support timeouts on socket operations; or for specially
    coded loops that use the check_alarms function.  This is a large
    inconsistency... but there is a reason for it:  it is difficult to
    do otherwise in a multithreaded app.

    Every resource I've read regarding threading indicates that
    asynchronous cancellation is a Bad Thing.  Apache 1.x timers
    essentially are asynchronous cancellation... and the longjmp()/EINTR
    issues are just good examples of why async cancellation is a bad
    thing.

    For NSPR the timeout model is completely revamped.  It is a
    synchronous model.  There's no core support for it beyond the
    timeout option on BUFFs.  The client socket will always have a
    timeout associated with it, thus eliminating the potential for
    programmer error.  If modules wish to open other sockets (i.e. the
    proxy, or rfc1413) they can put whatever timeout they desire onto
    the BUFF; or they can use the NSPR PR_Send/PR_Recv interface directly.

    In this model the only types of timeouts supported are "soft".
    So it's possible that for efficiency we'll need to add more "aborted"
    checks in various loops and such.  But that's an efficiency, not
    correctness issue.

    If a something absolutely needs timeouts for other operations,
    then it will need to use NSPR primatives to construct the timeout.
    For example it could use interval timers and do explicit checks in a
    computation loop.  See lingering_close() in http_main for an example.
    But I suspect the need for this is extremely low -- it's generally a
    bad idea to have something so CPU intensive that you're worried it'll
    go for too long, because you're throwing away CPU if you do that.
    It's pretty easy in that case to end up with not enough CPU to serve
    any requests.

    ap_is_aborted() tests if a connection has been aborted.  (Used to
    be conn->aborted.)

    All of kill/hard/soft/reset_timeouts are gone.  Just delete them,
    it's handled transparently for almost everything.  If you really
    want to change the timeout name for log messages do it in,
    r->connection->timeout_name ... but even that isn't required,
    as the core will make sure it says "during handler processing"
    for example, and (eventually) the url will be there with it.

    block_alarms() and unblock_alarms() are gone.  There are no
    critical sections because longjmp() is gone.