httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: [PATCH] select-thread-hybrid-01.patch
Date Wed, 19 May 1999 06:21:10 GMT
On Tue, May 18, 1999 at 09:52:38AM -0700, Dean Gaudet wrote:
> I'm attempting to make use of the response queue right now.  Except I'm
> running into the total mess that buff.c is

Random mumblings...

There are a lot of changes that would be good to make to buff.c, like
sendfile/TransmitFile API support, which is a basic structural change.
It's probably easier to add this support at the same time as any other
rewrite of buff.

As a first cut, the event thread could just use the standard I/O calls
instead of going though buff. This would make the event thread usable
only for static content, though, but we'd be able to delay biting off
buf rewrite until later. Is there any reason we need to use buff for
static content?

> I'll probably end up ripping out the non-unix stuff from buff.c -- yet
> another thing which we can fix later (given my current main only supports
> unix this isn't a problem). 

Everything needed by buff.c should be abstracted out by the PR, so
this is a good thing.

> FWIW, here's the list of responseq messages I expect:
> RESPONSEQ_SEND_MMAP,		/* copy from memory to BUFF */
> RESPONSEQ_SEND_FILE,		/* copy from file to BUFF */
> RESPONSEQ_SEND_PIPE,		/* copy from pipe to BUFF */
> RESPONSEQ_LINGERING_CLOSE,	/* handle lingering close */
> RESPONSEQ_WAIT_FOR_READ,	/* handle persistent connections */
> There will be corresponding WORKQ messages to indicate those are complete.
> And then we'll probably realise that we should have only one message
> type and combine the two.

To solve the blocking disk problem, we could add a WORKQ message to
read/mmap from a file not cached and pass back the results, making the
server look more like Flash. Of course, if we did this, there's no
reason that the worker thread couldn't also write the block out if the
block size < SO_SNDBUF.

> The difficulty that I'm running into is that I need to make all fds
> non-blocking, and the BUFF using the fd needs to know if the caller
> expects blocking or non-blocking behaviour... and that totally interferes
> with the {send,recv}withtimeout stuff... which is what lead me into the
> mess of buff.c :)

I need to dip into buff.c more than I have, but a little change to
{send,recv}withtimeout should give it both blocking and non-blocking
behavior, right? Just let sec == -1 mean no timeout instead of sec ==
0.  Then, {send,recv}withtimeout can be made non-blocking on a whim.

In fact, if buff can assume that the socket descriptor is always
nonblocking, this should actually make the code simpler.

Manoj Kasichainula - manojk at io dot com -
"How can one live in this age and not be curious?" -- Charles Krauthammer

View raw message