> 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?
Cheers,
Simon
___
Gl
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
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 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 r
On Fre, 2002-03-15 at 12:52, Simon Marlow wrote:
> > There's no bug in the libraries:
> > The data is read lazily by 'getContents', then you invoke
> > 'forkProcess'.
> > From this moment on, you should have two (heavy-weight)
> > processes competing
> > for input from the same source (stdin).
>
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 resul
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
> 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
> > 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 >> exec
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 buff
On Mon, 2002-03-18 at 13:51, Simon Marlow wrote:
> Ok, here's my explanation. [...]
I see...
Yet, it doesn't explain why the problem disappears if you close stdin
before calling executeFile, like this:
callIO :: (ProcessStatus -> String)
-> IO ()
-> IO ()
callIO fm io = do
ma
> On Mon, 2002-03-18 at 13:51, Simon Marlow wrote:
> > Ok, here's my explanation. [...]
>
> I see...
>
> Yet, it doesn't explain why the problem disappears if you close stdin
> before calling executeFile, like this:
>
> callIO :: (ProcessStatus -> String)
>-> IO ()
>-> IO ()
>
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 b
> 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. Th
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
su
> * 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 me
On Die, 2002-03-19 at 14:32, Simon Marlow wrote:
> > 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.
>
> I don't think mmap() provides exactly the right behaviour. It lets you
> specify that modific
> > 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 lo
19 matches
Mail list logo
