Jim Davidson wrote:
Cool. The driver thread is technically a single threaded thing which
shouldn't block and the connection return functions are blocking but
as the response is small, it probably just works. Also, the
connection code hasn't been verified to run in the driver (filters,
traces, etc.) but again it likely just works unless there's a really
goofy, blocking, involved filter lurking in some installation.
This has always worried me about using pre-queue filters - they run in
the driver thread which you really don't want to block, and a lot of
interesting things to do there a web service can easily block or need to
be carefully written to not block.
Naturally, I have ideas for a solution :)
One way would be to (optionally) have a separate thread pool for
pre-queue filters, similar to how reading can be done in separate
threads. I don't think this would be terribly difficult, but then I
haven't tried it yet.
My other idea is to let connections "restart" after finishing up in
their conn thread. That is, after processing is done, rather than
cleaning up the conn and closing the socket, kick it back to the
driver's prequeue state and run it again from the very beginning, the
only difference being that the conn processing may have setup quewaits
or cls data, or changed the url. This approach could let you set up
complex state machines with lots of processing in each state. I looked
into doing this a little, and it's complicated, because you have to
abort the cleanup that normally happens when the conn is done, which can
happen in several places. This complexity is probably unwarranted for
most things, but it would allow 'expect: 100-continue' handling after
authentication (if the conn was moved back to the readwait state).
A more involved, perhaps unnecessary solution would be to either move
all the response writing back to the driver in non-blocking I/O mode
for all requests and/or taking error condition connections and simply
tightening them up and sending them to a connection thread to
generate the response safely. Hmm.... The later is probably
safer/easier and more backward compatible but the former concept
always intrigued me.
I really like the idea of making the response writing nonblocking. It
would make everything symmetrical, and could avoid the possibility of
tying up conn threads writing a large response (like a file download).
I know there are ways of handling that particular problem, but having it
not be a problem in the first place would be better.
-J
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<lists...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
