forkIO on GHCI does not seem to spawn the thread in the background on some OSs
Hi, I found that on windows and my ubuntu box, when I did this ghci> t <- forkIO someAction "someAction" started executing in the foreground - as in, the ghci prompt did not come back (until I pressed Ctrl-C) On my mac however, when I ran the same thing, the action started executing in the background and ghci> prompt returned instantaneously. How can I get the thread backgrounded explicitly? Regards, Kashyap
On Monday, February 7, 2011, C K Kashyap <ckkashyap@gmail.com> wrote:
Hi,I found that on windows and my ubuntu box, when I did this ghci> t <- forkIO someAction "someAction" started executing in the foreground - as in, the ghci prompt did not come back (until I pressed Ctrl-C)
On my mac however, when I ran the same thing, the action started executing in the background and ghci> prompt returned instantaneously.How can I get the thread backgrounded explicitly?
It is not always a thread. ForkIO creates a spark and then the scheduler decides when sparks should be scheduled to threads. Thus you get a guarantee of concurrent but not parallel execution. Are you running with threads enabled?
Regards,Kashyap
From: David Leimbach, Sent: Tue, February 8, 2011 8:07:39 AM On Monday, February 7, 2011, C K Kashyap <ckkashyap@gmail.com> wrote:
Hi,I found that on windows and my ubuntu box, when I did this ghci> t <- forkIO someAction "someAction" started executing in the foreground - as in, the ghci prompt did not come back (until I pressed Ctrl-C)
On my mac however, when I ran the same thing, the action started executing in the background and ghci> prompt returned instantaneously.How can I get the thread backgrounded explicitly?
I can't reproduce this. What are you using as the action? I've tried bottoms, and tight loops whose Core contains no allocations, and not managed to lock up the prompt, or seen ghci using more threads than I have cores. One thing that may give the appearance of locking up the prompt is if the thread starts reading from the terminal and your commands no longer make it to the interpreter.
It is not always a thread. ForkIO creates a spark and then the scheduler decides when sparks should be scheduled to threads. Thus you get a guarantee of concurrent but not parallel execution.
That is not correct - it is "par" that creates sparks may be discarded. forkIO always creates new threads, though it is of course up to the scheduler when the threads are executed, and how many cores are used.
Are you running with threads enabled?
That is, was your ghci compiled with -threaded? This mostly depends on the version. what version of ghc are you running, and how did you install it?
I can't reproduce this. What are you using as the action?
I've tried bottoms, and tight loops whose Core contains no allocations, and not managed to lock up the prompt, or seen ghci using more threads than I have cores.
One thing that may give the appearance of locking up the prompt is if the thread starts reading from the terminal and your commands no longer make it to the interpreter.
It is not always a thread. ForkIO creates a spark and then the scheduler decides when sparks should be scheduled to threads. Thus you get a guarantee of concurrent but not parallel execution.
That is not correct - it is "par" that creates sparks may be discarded.
forkIO always creates new threads, though it is of course up to the scheduler when the threads are executed, and how many cores are used.
Are you running with threads enabled?
That is, was your ghci compiled with -threaded? This mostly depends on the version. what version of ghc are you running, and how did you install it?
Sorry ... extremely sorry ... my bad ... for some reason, I was omitting
the call to forkIO :( when I was trying on other platforms. Regards, Kashyap
On Tuesday, February 8, 2011, C K Kashyap <ckkashyap@gmail.com> wrote:
I can't reproduce this. What are you using as the action?
I've tried bottoms, and tight loops whose Core contains no allocations, and not managed to lock up the prompt, or seen ghci using more threads than I have cores.
One thing that may give the appearance of locking up the prompt is if the thread starts reading from the terminal and your commands no longer make it to the interpreter.
It is not always a thread. ForkIO creates a spark and then the scheduler decides when sparks should be scheduled to threads. Thus you get a guarantee of concurrent but not parallel execution.
That is not correct - it is "par" that creates sparks may be discarded.
forkIO always creates new threads, though it is of course up to the scheduler when the threads are executed, and how many cores are used.
Are you running with threads enabled?
That is, was your ghci compiled with -threaded? This mostly depends on the version. what version of ghc are you running, and how did you install it?
Sorry ... extremely sorry ... my bad ... for some reason, I was omitting the call to forkIO :( when I was trying on other platforms. Regards,Kashyap
:-)
It is not always a thread. ForkIO creates a spark and then the scheduler decides when sparks should be scheduled to threads. Thus you get a guarantee of concurrent but not parallel execution.
That is not correct - it is "par" that creates sparks may be discarded.
I guess I should have been clearer. A forkIO thread is not an OS thread necessarily. Sparks may become threads or be discarded in the par sense.
forkIO always creates new threads, though it is of course up to the scheduler when the threads are executed, and how many cores are used.
Yes, this is my understanding as well.
participants (3)
-
Brandon Moore -
C K Kashyap -
David Leimbach