httpd-dev mailing list archives

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

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

The abstraction is necessary.  There are some operating systems that don't
want to use a complex messaging system like what you are implementing.  I
am thinking of one platform already that has already expressed an interest
in using another method for accepting connections.  Plus, we most
definately don't want the server on a non-threaded system to use the same
accept model as a threaded platform.  Everything I have heard from the
group is that the hybrid server must be able to run in both thread-only
and process-only mode.  The accept model abstraction makes this possible.

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

Those timeouts were put in because we needed them to be able to test.
When APR is included in the server, the nspr code can be moved over.  The
ap_(read|write) code already has timeouts, so the buff functions can be
cleaned.  I would suggest just hacking away until we get apr implemented
in the server.  :) 

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

That is the plan.

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

I really hope that when you say fds, you mean sds.  If you require all fds
to be non-blocking, including those actually referring to files on disk,
we have a problem.  There are too many platforms that do not support
non-blocking fds for files on disk.


Ryan Bloom
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	

View raw message