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
