Re: commloops and modio development

Adrian Chadd wrote:

> In any case I'm now at a point with modio and commloops where I need
> some help. I've killed all the deferred reads in the commloops
> code, and I've hit a problem with my store server callback idea.
> The problem is that if a client exits and the server is waiting
> for a 'kick' from the client to read more data, the server fd can
> sit there with no read/write handlers.

The server connection needs to be told when the last client disappears.
Not much that can be done about that. How it is done is another matter.

> This obviously sucks, and a better way of limiting incoming server
> data on the fly without "throwing away" IO events would be nice.

Sorry, but I am not entirely familar yet with how you have done things.
But sure, there are ways to do this without throwing away events.

> Optimally I'd like the solution to not require large amounts of
> incoming buffering from the network server side. This may be a
> tall order, but I would like to kill the use of the stmem routines
> to buffer network IO (and use them to buffer "auto generated"
> data by squid..)

I'll second this I think, and kill the feature that there can be
multiple clients listening to one server connection. Having the
possibility of multiple clients makes things quite complicated.

I'd also kill the ability to reattach to a "not-yet-aborted" request,
based on the assumption that we can implement storate of partial
objects.

So exacly how simple can "single client per server connection" get:
  * no need for deferred reading
  * no need for buffering

Why no need for deferred reads:

It is handled automatically by the dataflow. When the client wants data
you try to read. If there is no data then register for notification of
available data.

Why no need for buffering:

Data is immediately sent to the listening client.

Yes, there will be limited need for buffering while parsing the protocol
(HTTP headers or TE).

Operations needed on the stream:

stream = open(...)
read(stream, *read_callback, cbdata)
write(stream, buffer, write_callback, cbdata)
abort(stream)
close(stream)

read_callback(buffer, status, cbdata)
write_callback(status, cbdata)

abort() prematurely tears down the stream, killing any pending
notification requests.

/Henrik
Received on Fri Jan 12 2001 - 14:45:01 MST