httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: [PATCH] select-thread-hybrid-01.patch
Date Tue, 18 May 1999 16:52:38 GMT

On Mon, 17 May 1999, Manoj Kasichainula wrote:

> With the changes so far, I think this code can fit back into the
> accept abstraction stuff that's in the apache-apr repository right
> now.  Making use of the response queue will require changing the
> abstraction, though.

I don't think the abstraction is worth keeping -- you had only one
"message type" essentialy.

I'm attempting to make use of the response queue right now.  Except I'm
running into the total mess that buff.c is ... damn this was a LOT more
clean in apache-nspr.  You guys just wedged in timeouts in a haphazard,
incomplete way.  Now I'm debating on looking at APR or just hacking
things up more...  my aesthetic sense has me puking at the moment though,
so I'm derailed.

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). 

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.

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 :)


View raw message