Export runInteractiveProcess_lock on Posix systems

[thomasjm]

This PR is to help fix merijn/posix-pty#15.

Summary: on Posix systems, System.Process must take certain precautions before using the fork system call. These include altering global state by calling blockUserSignals and stopTimer() before forking; see https://github.com/haskell/process/blob/master/cbits/runProcess.c#L137.

However, System.Process is not the only library that might need to use fork. System.Posix.Pty is another such library -- it uses the forkpty call (which internally does fork) to create a process attached to a pseudo-terminal. Thus System.Posix.Pty also needs to take these precautions.

As a result, we need to ensure mutual exclusion between System.Posix.Pty fork calls and System.Process fork calls, or else they stomp on each other's changes to global state. The only way I can see to do this is to use the same lock, so this PR exports it. I made a PR on posix-pty to leverage it here: merijn/posix-pty#16.

Of course, this feels like a bit of a band-aid since it only ensures that interleaving these two libraries is safe. Other libraries that might want to fork will still run into problems interleaving with these libraries. It would be nice to get some GHC expert attention on this but maybe that's an issue for another tracker.

[snoyberg]

I don't feel strongly either way, but overall I'm concerned that there may be undocumented invariants, and exposing this locking primitive will end up encouraging misuse.

[thomasjm]

Yes, agreed this is not pretty but it seems to be forced by the design of the RTS. If there were some facility provided by the language itself to ensure that an FFI fork call is safe, then libraries wouldn't have to come up with their own locking schemes.

As it stands, other libraries can't safely fork if that operation might get interleaved with a System.Process call, and I think we should fix that ASAP. For me it produced a quite nasty intermittent livelock bug. Surfacing this flaw might help other people avoid the same while a more principled fix is investigated.

It seems like a reasonable compromise to put it in System.Process.Internal, no? That kind of communicates the sketchiness of the fix and allows us to remove it someday later.

[snoyberg]

Fair enough. In that case, can you add a changelog entry, and some Haddocks on the lock explaining what it is and why it's exposed, possibly with a link to this PR?

[thomasjm]

Done!

[snoyberg]

Thank you!

[thomasjm]

Np! Any chance I could get you to cut a Hackage release @snoyberg ?

[snoyberg]

Done!