httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject apache-nspr-01.tar.gz
Date Mon, 27 Apr 1998 08:43:29 GMT

It compiles for me.  I haven't run it.  I'm in wholesale rewrite mode
still -- all of the unix system and library calls that NSPR supercedes are
being replaced.  A lot of the work is done, still probably another 8 to 10
hours of mostly search-and-replace before I get to the testing point. 

There are XXX comments all over the code where I just didn't do something

Many changes to the buff.c, and alloc.c interfaces; and to various
structures in httpd.h. 

I've made a few changes to the NSPR library, nothing you should need to
compile this.  Mostly just to deal with -Wall -Wshadow warnings.  I'll
package all of that up later. 


Here's the src/README.NSPR file:

My plan is to completely replace all Unix system calls, and types
with the NSPR calls and types.  From what I've done so far I feel
the Apache code is going to look a lot more clean.  There are
far fewer #ifdefs and special cases.

The "process model" will be somewhat similar to the current unix
model -- a "parent" thread, and multiple "children" threads in a

When I'm not so completely zoned I'll write more here.


- clean up timeouts, all the timeout routines in http_main are
  commented out
- implement ebcdic as a layer ?
- implement chunking as a layer
- need ap_slack functionality, probably has to be inside NSPR
- errno is useless, need to start using PR_GetError and such
- mmap/transmitfile
- clean up the messy hacks that I made for hostname/addr parsing
  and such... should be able to grep for XXX:.*ipv6

NSPR thoughts/nits/questions:

- buffered i/o:
    They don't have any buffered I/O... I'm trying to figure out the
    cleanest way to put BUFFs on top of the layers.  I'll probably make
    the buffering a layer itself... but there's no flush function to
    run down the layers.

    I think they think that buffered i/o can just sit on top of all the
    layers.  That's fine... until you consider pipelined connections,
    and chunking.  I want chunking to be a layer; but if it's below
    the buffering layer then it will shred up the output into many
    packets... either that or we implement buffering in the chunking
    layer too.  Which isn't actually that bad -- but again, there's no
    flush function.

    I can't see how they would ever get more than one response per packet.
    Maybe they're happy with "shredding" the pipeline, but I'm not.

    I'm pretty sure I can deal with all of this without even touching
    the NSPR source code; but a better solution would be to add a flush
    method to the layers, all the default layers would have it as a nop.

- multiple process models:
    I haven't seen anything that scares me.  Most of this stuff is just
    wrappers around traditional unix calls.  We just need someone to
    write a NSPR "compatibility" library which calls the unix calls
    directly...  most of the pieces are already in nspr because the
    pthreads implementations can call the unix calls directly.

    The rest is just initialization -- and that's one of the things in
    my process model doc that I think is right ;)

- timeout confusion:
    PR_Writev takes a timeout, PR_Write and PR_Read don't.

    PR_Recv and PR_Send do take timeouts but claim only to work
    on sockets, which seems like a silly restriction, they should
    transparently work on files -- I haven't checked.  I always get
    confused by how send/recv differ from write/read on SOCK_STREAM
    sockets... I don't think there's any difference, message boundaries
    are ignored I think.

    I see no way to implement the current style of timeouts on unix which
    can abort any operation.  This is similar to our current win32... and
    probably just a fact of threaded life.  I was intending to implement
    timeouts in pthreads using pthread_kill... doesn't look like this
    exists in NSPR, probably due to portability constraints.

- NSPR needs const for various parameters:
    PR_Write, PR_Send need it for the buf
    PR_Bind needs it for the addr

- docs don't really say if concurrent threads can access the same

- not clear if the size parm to PR_NetAddrToString specifies the
    size of the string... and if so if it guarantees nul term.
    Assuming this is the case.

- do you need to clear out_flags in PRPollDesc prior to calling
    PR_Poll()?  Assuming yes.

- what is the correct way to compare two PRNetAddrs for equality?

View raw message