Proposal: overhaul System.Process

[David Roundy]

On Thu, Jun 19, 2008 at 04:20:52PM -0700, Frederik Eaton wrote:
> David Roundy-2 wrote:
> > createProcess is (so far as I can tell) the lowest-level *portable*
> > Haskell API for spawning processes that has yet been proposed, in the
> > sense that there are no other proposed functions that could be used to
> > implement createProcess, and no other proposed functions that cannot
> > be implemented using createProcess.
> 
> It sounds like we are confusing "low-level" with "powerful". I don't know
> enough about portability and the constraints imposed by portability to
> comment on what else could be done, but the fact that we keep changing
> interfaces for process execution suggests to me that the existing interfaces
> have not been low-level enough. For instance, why can't we create a pipe
> independently of a process? What about creating pipes to file descriptors
> other than standard input/output/error? If we had good Haskell interfaces to
> OS-level primitives, as John Meacham suggested, then we could build
> something that tries to be a "greatest common denominator" on top of these.
> I am skeptical that the result would look very much like 'createProcess',
> for instance doesn't Windows have a concept of file descriptors other than
> standard input/output/error? I suppose that I can always use
> System.Posix.Process, though, and hope that it doesn't change too much...

The problem presumably is that there isn't sufficient similarity
between systems to create smaller components which are themselves
cross-platform that can be combined to write a function like
createProcess.  I don't know enough windows programming to confirm or
deny whether it would be possible to create a cross-platform
pipe-creation function, but I doubt it would be possible to create
something with semantics sufficiently similar to posix pipes so as to
be useful.

There's certainly no guarantee that there exist "small" cross-platform
pieces that can be used to construct a powerful process-spawning
function.  Perhaps Simon can enlighten us?

I just did a bit of a search and came across a bit of API from
microsoft:

http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx

It looks vaguely similar to the posix approach: you create pipes,
create backup copies of whichever of stdin/out/err you wish to change,
set your stdin/out/err to the values you wish to pass to your child
process, spawn the process, then you set stdin/out/err back to your
saved values, and maybe close one end of the newly-created pipes (I'm
not sure of this).

Under posix, the order is different, which probably means that you
can't break this into smaller pieces.  Under posix, you fork first,
and only then do you modify stdin/out/err and close one end of any
pipes you might have created, and then call exec.  Since the order of
operations is different, we can't write a portable version of Simon's
createProcess out of pretty smaller pieces.  Obviously, we could
write it out of functions like forkIfWeAreRunningPosix, etc, but
that would be stupid.

That's my half-baked analysis, based on reading a couple of web
pages...

David