Re: new module pipe-filter

[Bruno Haible]

Hi Paolo,

Thanks for the comments!

> I don't like very much the design of this module.  The problem is that 
> it requires excessive effort on the child's part to buffer writes and/or 
> to prepare all of the filter's input upfront.

You mean, on the parent's part, I guess? (The module's goal is precisely
to do more work in the parent, so that clients which do reasonable
buffering don't cause deadlocks.)

> A nicer interface IMHO could be:
> 
>     The caller will write to the subprocess through filter_write; during
>     calls to filter_write, the done_read function may be called to
>     process any data that the subprocess has written. ...
>     The done_read function may be called in a different thread than
>     the current thread, depending on the platform.

You are right that my proposed module is specialized for the case that
  - the control structure of the writer is simple, AND
  - the control structure of the reader is simple,
so that both can be dissected in repeated calls of the same function.

Your proposal is more general, but still assumes that
  - the control structure of the reader is simple.

A symmetrical proposal could be done for the case that
  - the control structure of the writer is simple.

And finally, in the case that both the reader and the writer part are
complex, the best bet is to do real multithreading on all platforms
(using the 'thread' module), while saying "not implemented" on exotic
platforms like Haiku or Interix.

Is there demand for these three other use-cases? I implemented only
the first one because that happened to be the one I needed in 'msgfilter'.
I am open to your requirements.

Bruno