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
signature.asc
Description: This is a digitally signed message part
