Avoiding deadlocks

[pcapriotti]

Is process-conduit completely deadlock-safe?

I tried implementing the same concept on top of pipes-core, and I haven't been to address the case where an upstream pipe is blocked on a monadic action, while some process downstream has data available. The problem is that until a pipe yields (i.e. goes into the HaveOutput state in conduit-speak), there's no way to awake any downstream pipe.

I believe the same holds for conduits, so I'm wondering how process-conduit addresses this issue, if at all.

As a concrete example, assume you have something like:

socketSource $= [cmd| slow filter|] $$ fileSink

and you get a single chunk out of the source. After that, assuming the filter hasn't had a chance to process it immediately, the pipeline will be blocked on the monadic action in socketSource. How can you unblock it as soon as "slow filter" is ready?

[tanakh]

I have recognized this problem. Both upstream and downstream have possibilities to deadlock. Upstream data do not depend on process-pipe, so ideally, Check downstream first, then if no data available, wait upstream data with blocking. (But buffering do bad things... it still may be deadlock.)

To solve this problem easily, fork two threads for reading upstream and downstream. But I was no idea to fork thread in Pipe monads. Are there a good idea to do this?