...

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

From: David Leimbach, Sent: Tue, February 8, 2011 8:07:39 AM On Monday, February 7, 2011, C K Kashyap wrote: 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?

On Tuesday, February 8, 2011, C K Kashyap 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

:-)