Don't block FRP network if writing to stdin blocks

[meditans]

This PR solves #9

The way this was done is adding a TChan to act as an unbounded buffer between the FRP network and the stdin handle. There's also a test suite that checks for this property. I suggest running the test suite with:

nix-shell -E '((import ./reflex-platform {}).ghc.callCabal2nix "reflex-process" ./. {}).env' --run 'cabal test --test-show-details=streaming'

so that one can check both the output of the cat process, and the eventual messages that arise from a blocking process (for now, I have a broken pipe that arises from the way I'm handling the finally clause in the test suite).

[tomsmalley]

Seems reasonable, but we should move the headless host stuff elsewhere.

[lspitzner]

I am mildly certain that TChan is overkill. Control.Concurrent.Chan would do, and even Data.IORef.IORef using atomicModifyIORef would work. Afaik, IORef [a] serves fine as a channel as long as you have a single consumer that can always drain all elements (EDIT: and the consumer must not need to block, which this code does need.) Which you could do here, even though it adds a bit of boilerplate.

I'll let the maintainers of this decide whether they want the IORef performance or the Chan maintainability.

[lspitzner]

Oh wait, IORef cannot block. Whoops. Needs Chan.

[3noch]

@lspitzner The only reason we went with TChan is it affords a slightly nicer API if you need it, but seeing that we're not exposing the channel itself it's probably moot.

[3noch]

@lspitzner I think we should actually expose the TChan which makes me prefer TChan over Chan because TChan has a much richer API, particularly if you hope to build a pressure relief valve since it is unbounded.

[lspitzner]

true, I approve.

[3noch]

Then again, just abstracting this a bit more makes the choice of channel a trivial configuration. Will go that route instead.

Comments have been resolved