I don't think mmap() provides exactly the right behaviour.
It lets you
specify that modifications made by the current process
aren't committed
to the file, but what we want is to snapshot the file so
that subsequent
modifications by *other* processes aren't seen by the local
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
I've been following this discussion with some interest. It seems to
me on important underlying problem is being hinted at, but has never
been made explicit:
* When we fork(), we lose sharing. *Any* lazy computation which
passes to both children is going to penalize you, sometimes in very
* When we fork(), we lose sharing. *Any* lazy computation which
passes to both children is going to penalize you, sometimes in very
surprising ways.
I'm not sure I understand why loss of sharing is the problem - losing
sharing for pure computations is by no means a disaster, it just
On Fre, 2002-03-15 at 15:05, Volker Stolz wrote:
Am 15. Mar 2002 um 14:39 MET schrieb Volker Wysk:
- If instead the child's child (echo.c) closes stdin
immediately after
being executed, some data is lost.
Where's the use in closing stdin when you're passing arguments as
Yes, it's a NOP (just to be sure). The difference is in child.hs:
callIO (\ps - Kommando fehlgeschlagen mit ++ show ps
++ :\n ++ kommando prog par)
(executeFile' prog True par Nothing)
-- instead, to avoid bug:
-- (hClose stdin executeFile' prog True
Am 18. Mar 2002 um 13:51 MET schrieb Simon Marlow:
unevaluated until the child process needs to construct its argument list
to pass to executeFile. Hence the child process pokes on the lazy
stream, and when the parent process subsequently demands data from the
lazy stream, there is a
In local.glasgow-haskell-bugs, you wrote:
I've stripped down my program to produce an example. In the process, the
problem disappeard a few times. I hope it shows up on your machine. The
attached files reproduce it on my machine, but the exact results vary
from run to run.
There's no bug in
In local.glasgow-haskell-bugs, you wrote:
I've stripped down my program to produce an example. In the
process, the
problem disappeard a few times. I hope it shows up on your
machine. The
attached files reproduce it on my machine, but the exact
results vary
from run to run.
Just to be sure, I've changed to example program a bit (see attachment).
I think it now demonstrates clearly that there must be a bug in the
libraries.
- If the child closes its child's stdin before calling executeFile, all
data gets through.
- If instead the child's child (echo.c) closes stdin
Am 15. Mar 2002 um 14:39 MET schrieb Volker Wysk:
- If instead the child's child (echo.c) closes stdin immediately after
being executed, some data is lost.
Where's the use in closing stdin when you're passing arguments as
parameters? This is effectively a NOP and shouldn't influence the
On Fre, 2002-03-15 at 15:05, Volker Stolz wrote:
Am 15. Mar 2002 um 14:39 MET schrieb Volker Wysk:
- If instead the child's child (echo.c) closes stdin immediately after
being executed, some data is lost.
Where's the use in closing stdin when you're passing arguments as
parameters? This
On Mon, 11 Mar 2002, Simon Marlow wrote:
There seems to be a bug in the IO libraries. I'm using the following
procedure to call an external program and send it data through a pipe.
Could you send us a complete example that we can run to reproduce the
problem?
I've stripped down my
13 matches
Mail list logo
