RE: Signals + minimal proposal (was Re: asynchronous exceptions)

2006-04-11 Thread Simon Marlow
On 10 April 2006 22:19, John Meacham wrote: On Fri, Apr 07, 2006 at 02:58:01PM +0100, Simon Marlow wrote: According to your definition of exitWith above, I can't both raise an exception *and* exit in the same thread. If I register an onExit handler that throws an exception to the current

Re: Signals + minimal proposal (was Re: asynchronous exceptions)

2006-04-11 Thread John Meacham
On Tue, Apr 11, 2006 at 08:54:32AM +0100, Simon Marlow wrote: now If I have a handler registered that throws an exception to the current thread, what happens? handleLoop is aborted, the exception is propagated to the top level of the thread, where the top-level exception handler calls

Re: Signals + minimal proposal (was Re: asynchronous exceptions)

2006-04-11 Thread David Roundy
On Mon, Apr 10, 2006 at 02:19:23PM -0700, John Meacham wrote: On Mon, Apr 10, 2006 at 02:58:20PM +0100, Simon Marlow wrote: Suppose I want to do some action with a temporary file: bracket newTempFile (\f - removeTempFile f) (\f - doSomethingWith f) Under

Re: Signals + minimal proposal (was Re: asynchronous exceptions)

2006-04-10 Thread John Meacham
On Mon, Apr 10, 2006 at 02:58:20PM +0100, Simon Marlow wrote: Suppose I want to do some action with a temporary file: bracket newTempFile (\f - removeTempFile f) (\f - doSomethingWith f) Under your scheme, this code doesn't get to remove its temporary file on

RE: Signals + minimal proposal (was Re: asynchronous exceptions)

2006-04-07 Thread Simon Marlow
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

RE: Signals + minimal proposal (was Re: asynchronous exceptions)

2006-04-07 Thread Simon Marlow
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

RE: Signals + minimal proposal (was Re: asynchronous exceptions)

2006-04-07 Thread Simon Marlow
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

Re: Signals + minimal proposal (was Re: asynchronous exceptions)

2006-04-07 Thread John Meacham
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,