On 07 April 2006 00:36, Marcin 'Qrczak' Kowalczyk wrote:
Simon Marlow [EMAIL PROTECTED] writes:
I agree with your assessment of the problems with interruptible
operations in GHC: that it is impossible to completely block async
exceptions across a computation. We could certainly add a way to
On 06 April 2006 23:20, John Meacham wrote:
I'm not proposing that we ignore signals, just that we should clearly
delimit the platform-specific bits, perhaps by putting signal support
into an addendum.
yeah, I was thinking a separate environment addendum should be in the
report, which
On 07 April 2006 13:24, David Roundy wrote:
The catch to this [no pun intended]
is that when the main thread exits all other threads are silently
terminated, without the chance to clean up...
This is a mistake in GHC, I think. When someone calls exit, or when the
main thread exits, all the
On 07 April 2006 13:58, John Meacham wrote:
all threads keep running while the exit handers are running, all
blockExit would do is grab and release an MVar. exit itself takes
that MVar on starting to get rid of races to exit as well as protect
itsesf from 'blockExit' (but won't ever put the
Simon Marlow [EMAIL PROTECTED] writes:
BTW, I just realised a better way to express block. If block is
supposed to count nesting, then we have a problem that you can still
unblock exceptions even within a block by using sufficient number of
unblocks, so the right way is to give block this
On Fri, Apr 07, 2006 at 02:58:01PM +0100, Simon Marlow wrote:
Of course you could implement some global flag to say that an exit is in
progress, but that implies explicit checking of the flag all over the
place, which is what asynchronous exceptions are designed to avoid.
When *do* we exit,
