pass off sending to select loop?

[Marc Slemko <ma...@worldgate.com>]

Has anyone looked at passing off connections to a seperate process via
descriptor passing, then that processes multiplexes sending for however
many descriptors you want?

That way the main httpd process only handles reading the request, doing
the processing up to the point where the headers are sent, then it gets
out of it if it is a simple static request that send_fd can handle.

The obvious problem is that some phases of the API get tossed out the
window.  Things as basic as logging work very differently or have a
different meaning (eg. a log message could log an unknown size which
indicates that the file may or may not have been sent and may be any
size).  The user has to be willing to lose that functionality in return
for less processes. 

Also, descriptor passing is too slow to be worth it for small requests,
but for a site with lots of reasonably sized files this would be a win I
think.

On a threaded system, this could just be another thread which is better
because it avoids relatively slow descriptor passing.

This looks like a kindof cool idea to me.  Some other servers already do
it.  Basic implementation isn't that hard.

I'm playing with a proof of concept implementation and am starting to have
something that looks like it may partly work with some more effort... 

Re: pass off sending to select loop?

[Marc Slemko <ma...@worldgate.com>]

Oh yes, one thing I forgot to mention is that persistent connections are a
pain.  It should be easy to set it up to pass them back to a normal child
process for subsequent requests, the problem is the question of how much
overhead that presents.

On Sun, 4 Jan 1998, Marc Slemko wrote:

> Has anyone looked at passing off connections to a seperate process via
> descriptor passing, then that processes multiplexes sending for however
> many descriptors you want?
> 
> That way the main httpd process only handles reading the request, doing
> the processing up to the point where the headers are sent, then it gets
> out of it if it is a simple static request that send_fd can handle.
> 
> The obvious problem is that some phases of the API get tossed out the
> window.  Things as basic as logging work very differently or have a
> different meaning (eg. a log message could log an unknown size which
> indicates that the file may or may not have been sent and may be any
> size).  The user has to be willing to lose that functionality in return
> for less processes. 
> 
> Also, descriptor passing is too slow to be worth it for small requests,
> but for a site with lots of reasonably sized files this would be a win I
> think.
> 
> On a threaded system, this could just be another thread which is better
> because it avoids relatively slow descriptor passing.
> 
> This looks like a kindof cool idea to me.  Some other servers already do
> it.  Basic implementation isn't that hard.
> 
> I'm playing with a proof of concept implementation and am starting to have
> something that looks like it may partly work with some more effort... 
> 
> 

Re: pass off sending to select loop?

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

Given network latency and largely low speed clients you can probably hide
the extra latency of the syscalls required to pass the descriptor.  But
depending on how busy your site is, and what unix you're running I'm not
sure you'll really gain a lot.

If you're just trying to free up the child slot then you could create
another thread within each child to handle these things, and let the main
thread go back to child_main.  Signals are a pain though. 

Dean