On Mon, Mar 10, 2014 at 8:54 AM, Johan Tibell <johan.tibell@gmail.com> wrote:
On Mon, Mar 10, 2014 at 1:47 PM, Ian Lynagh <igloo@earth.li> wrote:
On Mon, Mar 10, 2014 at 02:32:06PM +0200, Michael Snoyman wrote:
> On Mon, Mar 10, 2014 at 2:30 PM, Johan Tibell <johan.tibell@gmail.com>wrote:
> > I propose we add it to System.IO. Note that we'd have to copy the 5 lines
> > in System.Posix.IO.createPipe into base as the above implementation would
> > otherwise depend on the unix package.
> >
> +1. I've needed this in the past when working with process, and ended up
> writing POSIX-only code as a result.

Would it make more sense to put it in process, and thus avoid needing to
copy/move code into base?

I'm certainly open to that idea. If the only uses of pipes are for processes, I think that makes sense. Are there any typical non-process uses of pipes? I can't think of any right now.

I know of one in C, and it seems potentially applicable to Haskell as well, but it's mostly(?) a Unix-ism: you allocate a pipe, write to it in a signal handler, and monitor the read end in an event loop (in Haskell, a thread) in order to change an asynchronous signal that may have happened when it's unsafe to e.g. allocate memory into a synchronous event that can be handled safely. Note that you must use an unbuffered write from System.Posix.IO to write from the signal handler safely, so this introduces a hard dependency on the `unix` package; although there may be a win32 equivalent.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b@gmail.com                                  ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net