> 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
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
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.
|