Malcolm Wallace wrote:
Had you deprecated the non-threaded RTS, we would probably have no
problems described in ticket #2848 :-/
I think you'll have to deprecate it anyway, because it will be more
and more difficult to maintain two versions of code,
we may conduct small survey on amount of
Brian B wrote:
Hi Bulat,
My contribution to the survey: I've used forkProcess to daemonize
a ghc program inside the haskell fuse bindings:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse
http://code.haskell.org/hfuse/System/Fuse.hsc
If removing the non-threaded RTS would break
John Goerzen wrote:
Brian B wrote:
Hi Bulat,
My contribution to the survey: I've used forkProcess to daemonize
a ghc program inside the haskell fuse bindings:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse
http://code.haskell.org/hfuse/System/Fuse.hsc
If removing the
Simon Marlow wrote:
John Goerzen wrote:
Brian B wrote:
Hi Bulat,
My contribution to the survey: I've used forkProcess to daemonize
a ghc program inside the haskell fuse bindings:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse
http://code.haskell.org/hfuse/System/Fuse.hsc
Simon Marlow wrote:
I would also add: does the threaded RTS support all platforms? For
instance, GHC runs on my Alpha and on AIX, unregisterised. ghci doesn't
run there, but GHC does. If you drop the non-threaded RTS, does that
mean that GHC doesn't work there at all?
If those platforms
Had you deprecated the non-threaded RTS, we would probably have no
problems described in ticket #2848 :-/
I think you'll have to deprecate it anyway, because it will be more
and more difficult to maintain two versions of code,
we may conduct small survey on amount of usage of old RTS
Hi Bulat,
My contribution to the survey: I've used forkProcess to daemonize
a ghc program inside the haskell fuse bindings:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse
http://code.haskell.org/hfuse/System/Fuse.hsc
If removing the non-threaded RTS would break forkProcess
Hello Tomasz,
Saturday, December 6, 2008, 10:52:39 PM, you wrote:
Had you deprecated the non-threaded RTS, we would probably have no problems
described in ticket #2848 :-/
I think you'll have to deprecate it anyway, because it will be more
and more difficult
to maintain two versions of
On Thu, Mar 1, 2007 at 5:21 PM, Simon Marlow [EMAIL PROTECTED] wrote:
In fact you should think of the non-threaded RTS as deprecated. It isn't
Haskell'-compliant, for one thing (assuming that Haskell' will probably
require non-blocking foreign calls).
I'm hesitant to actually deprecate it,
John Goerzen wrote:
On 2007-03-02, Simon Marlow [EMAIL PROTECTED] wrote:
Regarding your shell: I would suggest trying forkIO for the Haskell processes
(not forkOS unless for some reason you really need another OS thread). However,
I can imagine that it might be hard to implement job
Bulat Ziganshin wrote:
Hello Simon,
Friday, March 2, 2007, 1:07:07 PM, you wrote:
But let me add a voice to keeping the non-threaded RTS around.
i want to mention that problem here is not the threaded RTS by itself, but
standard i/o library that works via separate i/o manager thread that
is
On Mon, Mar 05, 2007 at 12:59:17PM +, Simon Marlow wrote:
There seems to be a common misconception that forkOS is necessary to get
certain kinds of concurrency, and forkIO won't do. I don't know where this
comes from: the documentation does seem to be quite clear to me. The only
On Mon, Mar 05, 2007 at 08:36:29AM -0600, John Goerzen wrote:
On Mon, Mar 05, 2007 at 12:59:17PM +, Simon Marlow wrote:
There seems to be a common misconception that forkOS is necessary to get
certain kinds of concurrency, and forkIO won't do. I don't know where this
comes from: the
Ian Lynagh wrote:
On Mon, Mar 05, 2007 at 08:36:29AM -0600, John Goerzen wrote:
On Mon, Mar 05, 2007 at 12:59:17PM +, Simon Marlow wrote:
There seems to be a common misconception that forkOS is necessary to get
certain kinds of concurrency, and forkIO won't do. I don't know where this
On Mon, Mar 05, 2007 at 03:20:05PM +, Ian Lynagh wrote:
From reading the docs, it sounds like forkIO keeps everything in a
single OS thread/process. Doesn't this mean that a program that uses
forkIO instead of forkOS loses out on SMP machines?
You can use e.g. +RTS -N2 to use 2 OS
John Goerzen wrote:
On Mon, Mar 05, 2007 at 03:20:05PM +, Ian Lynagh wrote:
From reading the docs, it sounds like forkIO keeps everything in a
single OS thread/process. Doesn't this mean that a program that uses
forkIO instead of forkOS loses out on SMP machines?
You can use e.g. +RTS -N2
Hello Simon,
Friday, March 2, 2007, 1:07:07 PM, you wrote:
But let me add a voice to keeping the non-threaded RTS around.
i want to mention that problem here is not the threaded RTS by itself, but
standard i/o library that works via separate i/o manager thread that
is built-in part of RTS. my
On 2007-03-02, Simon Marlow [EMAIL PROTECTED] wrote:
Regarding your shell: I would suggest trying forkIO for the Haskell
processes
(not forkOS unless for some reason you really need another OS thread).
However,
I can imagine that it might be hard to implement job control and signal
Ok, what happens here is that in the forked process there is only a single
thread, the runtime kills all the other threads (as advertised). Unfortunately
this includes the I/O manager thread, so as soon as you do some I/O in the
forked process, you block.
It might be possible to fix this,
On Thu, Mar 01, 2007 at 03:06:22PM +, Simon Marlow wrote:
Ok, what happens here is that in the forked process there is only a single
thread, the runtime kills all the other threads (as advertised).
Unfortunately this includes the I/O manager thread, so as soon as you do
some I/O in the
John Goerzen wrote:
On Thu, Mar 01, 2007 at 03:06:22PM +, Simon Marlow wrote:
Ok, what happens here is that in the forked process there is only a single
thread, the runtime kills all the other threads (as advertised).
Unfortunately this includes the I/O manager thread, so as soon as you
On Thu, Mar 01, 2007 at 04:21:45PM +, Simon Marlow wrote:
Between that and the lack of support for forkProcess in Hugs, this
renders anything that needs to fork and then do I/O as being usable only
in GHC-compiled code. Which is sub-optimal, but livable anyway.
I guess I'm really
At Thu, 1 Mar 2007 11:38:54 -0600,
John Goerzen wrote:
On Thu, Mar 01, 2007 at 04:21:45PM +, Simon Marlow wrote:
Between that and the lack of support for forkProcess in Hugs, this
renders anything that needs to fork and then do I/O as being usable only
in GHC-compiled code. Which is
On Thu, 2007-03-01 at 11:04 -0800, Jeremy Shaw wrote:
Some open questions are:
a) how do you detect that you are running in the threaded RTS
Currently the nearest approximation is:
Control.Concurrent.rtsSupportsBoundThreads :: Bool
Duncan
___
Hi,
I've been hitting my head against a wall for the past couple of days
trying to figure out why my shell-like pipeline code kept hanging. I
found fd leakage (file descriptors not being closed), which disrupts EOF
detection and can lead to deadlocks. I just couldn't find the problem.
I
At Wed, 28 Feb 2007 11:15:04 -0600,
John Goerzen wrote:
You can see my test case with:
darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh
ghc -fglasgow-exts --make -o test2 test2.hs
I get an erro when I use that darcs command-line, and test2.hs does
not appear to be in the directory
On Wed, Feb 28, 2007 at 10:40:18AM -0800, Jeremy Shaw wrote:
At Wed, 28 Feb 2007 11:15:04 -0600,
John Goerzen wrote:
You can see my test case with:
darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh
ghc -fglasgow-exts --make -o test2 test2.hs
I get an erro when I use that
Hello,
Your first problem is just a line buffering issue. You need to
explicitly set the line buffer inside the child processes:
redir fstdin stdInput
hSetBuffering stdin LineBuffering
redir fstdout
On Wed, Feb 28, 2007 at 01:06:25PM -0800, Jeremy Shaw wrote:
Hello,
Your first problem is just a line buffering issue. You need to
explicitly set the line buffer inside the child processes:
redir fstdin stdInput
hSetBuffering
Hello,
Hrm, setting the LineBuffering mode had the side-effect of setting the
underlying file description to non-blocking mode. When the executeFile
process took over, it would die with an error about 'standard input
temporarily unavailable'. So, ignore that.
j.
At Wed, 28 Feb 2007 15:23:53
Hello,
Here is a simplified example that seems to exhibit the same behaviour,
unless I screwed up:
---
module Main where
import System.Posix
import System.IO
import System.Exit
main =
do putStrLn running...
(stdinr, stdinw) - createPipe
(stdoutr, stdoutw) - createPipe
31 matches
Mail list logo
