httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@ibm.net>
Subject Re: [PATCH] Compiler warning + 64-bit AIX cleanup in dexter mpm
Date Thu, 22 Jun 2000 01:48:58 GMT
> From: rbb@covalent.net
> Date: Wed, 21 Jun 2000 17:50:04 -0700 (PDT)
> 
> > > I have one suggestion that I would also like to try to remove this
> > > problem.  I would be interested in seeing if we have the same problem if
> > > we use select instead of poll.  
> > 
> > We wouldn't have the problem with select().
> 
> Why not just have dexter use select instead of poll then?  I realize this
> will actually require a larger re-write, but it will make all of the code
> make sense.  

select isn't a problem as far as I know...

>          I can just see somebody coming along in a year and trying to
> make the code easier to read/understand and undoing this change.  This
> means that we need to document the reasons behind this everyplace we run
> into this problem.

We have one instance to document thus far.

> > 1) ap_poll() is slower than poll() and dexter doesn't need the
> >    portability that ap_poll() gives it
> 
> When was this proven?  

every time I've ever looked at the ap_poll() code

>                       Does it really matter that the parent process runs
> a tiny bit slower when it is polling on sockets?

probably not...  

does it matter each of the worker threads runs a bit slower?

To me, it matters at least a bit... now if I had ever heard of
somebody trying to get dexter to work on a system without poll(), that
could change quite quickly :)

> Since when was it decided dexter doesn't need to be portable?  Currently,
> dexter uses pthreads, I didn't realize that was never going to
> change.  Does this mean that any platform that doesn't provide poll can't
> use dexter?  

It certainly doesn't mean that in the long term.  I'll accept that it
is great for dexter to run on platforms with no poll().  You are
100% correct there.

What we have in the short term is a simple problem with a trivial fix.

If somebody wants to fix it the hard way in order to solve big picture
issues at the same time, more power to them, but it is fair to point
out that it is a lot more work (yes, I am well aware of the fact that
we use ap_poll() in very similar situations elsewhere, but I am also
well aware of how easily mistakes slip in) and that it will be slower
when they are done.  I definitely don't think a conversion to
ap_poll() is justified by the unfortunate need for those several lines
of code if we keep poll().

I'm done for good on this one :)

Have fun,

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message