Bug in IO libraries when sending data through a pipe?

[Volker Wysk]

On Mon, 2002-03-18 at 18:30, Simon Marlow wrote:
> The spec could perhaps *require* that it was a pure value, so that the
> file contents is snapshotted at the time of the hGetContents and you
> always get the same result regardless of subsequent or concurrent I/O
> operations.  This can perhaps be implemented with copy-on-write if the
> OS supports it, but I don't know if any OSs actually do.

The mmap system call provides this, on Unix systems. The man page says
it's POSIX.1b standard, so it might even be supported by Windows 2000.

This strategy won't work for general IO streams (pipes, sockets...), of
course. If the spec would require all stream contents to behave like
pure values, this would limit lazy streams to files. So you could no
longer handle general streams and files the same way...


> > Likewise, it might be possible to define a set of process operations
> > which avoid mistakes like mine. 
> 
> Indeed, there definitely at least ought to be a cross-platform way to
> spawn a process.  The spawn operation needs to be "atomic" with respect
> to existing lazy I/O streams and concurrent threads, and the spawned
> process should continue concurrently with the current process (unlike
> System.system), but there should be a way to wait for it to complete in
> a non-blocking way in a multithreaded program.

The time between fork() and exec() seems critical. A safe, atomic
operation for starting an external program would be helpful. It would
make sure everything needed is fully evaluated, before forking the new
process.

I'm wondering if it is possible to let the programmer somewhat describe
what should happen, when accessing the world as lazily evaluated values,
so the compiler can test for correcteness. Some sort of annotations.
Perhaps this would be a research topic...

Cheers, Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
Url : http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20020319/8acf1a30/attachment.bin