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