Re: io pipe refactoring

Like it, except for the small detail that some effort should perhaps be
put into filtering of the pipe use not trigger a comm loop for events
already processed.

I fully agree that the mechanism whereby a subsytem can signal a async
event which needs to be polled from the comm loop separate from
filedescriptors indeed is a core component. Also allows for better
abstraction on different architectures (pipes is just one of many
alternatives for such signal).

Regards
Henrik

Robert Collins wrote:
>
> Any objection to the attached patch?
>
> It abstracts the comm interruption signal pipe back to the comm layer.
> Although only the aufs code needs it today, IMO it's logically part of
> the comm implementation, not the async implementation.
>
> Rob
>
> --
> GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.
>
> ------------------------------------------------------------------------
> Name: proposed_IOPipe.patch
> proposed_IOPipe.patch Type: Plain Text (text/plain)
> Encoding: quoted-printable
>
> Name: signature.asc
> signature.asc Type: application/pgp-signature
> Description: This is a digitally signed message part
Received on Wed Jan 08 2003 - 21:17:10 MST