httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject RE: [PATCH] accept serialization
Date Thu, 14 Aug 1997 07:50:18 GMT
On Wed, 13 Aug 1997, Paul Sutton wrote:

> I guess the includion of DEFAULT_TYPE -> DEFAULT_CONTENT_TYPE was a
> mistake? 

No I just forgot to comment about it.  DEFAULT_TYPE is defined by
pthread.h under Solaris.  So we have to make this change someday (assuming
we're some day going to use pthreads). 

> I'm not clear *which* OSes are safe to use SAFE_UNSERIALISED_ACCEPT with.
> Is this something we find out by trial and error? A test program for
> serialising would been nice.

Yeah this is something I'm not sure how to do.  The test rig for this is a
little more elaborate since you need to spawn a bunch of children, get
them into accept() and then launch a bunch of connects at it.  When I get
a spare cycle maybe I can write an uptodate tuning page... there are a lot
of knobs to be tuned.  A good thing for it would be a walk-through of the
process by which I got the server down to 29 syscalls by tuning things.

> On Fri, 8 Aug 1997, Dean Gaudet wrote:
> > Yeah but probably not until 2.0 ... which is a cop out :)  Actually in 2.0
> > we need more generic mutexes because threading will be an integral part of
> > the API. 
> Yeah, presumably a POSIX threads like interface would be nice, either
> mapped direct to OS calls (Solaris) or onto other threads layers (e.g
> Linuxthreads? I don't know). 

I've been giving thoughts to this ... especially in relation to NT (given
that I just spent a few days at an NT conference).  I'll post the thoughts
later though, too much email to catch up on right now.

> > I actually want to split the 5 methods (probably 6 if I can find something
> > to work on OSF/1, Ken's post is quite dismaying) into a file each... but I
> > figured people would balk if I put code into .h files and #include them
> > ... or if I put code into .c files and #include them. 
> I have no problem with #including compilable code. I like the concept of
> separating out the different locking implementations like this. 

It would make http_main.c almost readable.  Emphasis on almost :)

BTW, someone with root on IRIX, I would really appreciate it if you could
try the SYSVSEM solution, but comment out the part which changes the
ownership of the semaphore.  It's not clear to me from the semaphore
documentation if the ownership is checked on each semop.  If it is checked
on each semop then my comment about the DoS attack is valid... otherwise
we can just skip the ownership change.  (I don't have root on any IRIX box
at the moment.)


View raw message