At 11:59 AM 9/4/2002, Brian Pane wrote:
Aaron Bannert wrote:
On Wed, Sep 04, 2002 at 06:06:59PM +0200, Graham Leggett wrote:
Is it possible to read brigades from two filter stacks simultaneously?
No, and the need for multiplexed brigade read/writes has been
brought up before, but never fully designed nor implemented.
It's worth noting, though, that the building blocks for
doing this are already in place. The pollset API allows
you to pass in a void* associated with each file descriptor,
and it returns that void* whenever the fd is signalled in
a poll. So we have an efficient way of mapping an I/O
readiness state to the right brigade.
It isn't simply the brigade... it's the filter 'stack'. If we map that
into the brigade [as metadata, for example] that's fine.
The problem is that we need to be able to return a 'not ready'
v.s. 'more data' from ap_get_brigade or ap_write_brigade. In the
'not ready' case, we can return something useful [opaque fdset
members] that the caller can use to poll upon. If that poll succeeds,
the caller can try again.
Note that this is an fdset, not single fd's. Picture something like
mod_ext_filter. As rbb pointed out to me a while back, you can be
stuck on one of the following; The socket read from the client, the
file write to the external filter, or the file read from the external filter.
There is no way to know that you are stuck attempting to read from
the client v.s. reading from the external filter. Is the external filter
waiting for more data before it flushes? Or is it in a time-intensive
operation? The answer is, we just can't know.
So if we have a way to pass our apr_fd's or an apr_fdset back up
the brigade as metadata, we would have to poll on all of these in
order to decide when to re-query the input or re-write to the output
brigade. But as long as we remember this isn't a one-of sort of
entity, but multiple fd entries might be required to poll the input or
output brigade, I believe this puzzle can be solved.
Bill
