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 exit, unless I explicitly add an exit handler that throws an exception to the current thread.

I think code like the above should just work. Furthermore, I think it should be an invariant that a thread is never discarded or killed, only sent an exception. Otherwise, how else can I acquire a resource and guarantee to release it when either an exception is raised, the program exits, or the computation completes?

you ask the system to send you an exception on exit.

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 thread, things go wrong if the current thread also calls exitWith. Also, you couldn't call exitWith while holding an MVar, if the handlers need access to the same MVar.

hrm? nothing goes wrong. it is the same as calling 'throw' in the current thread. I don't see how it is unsafe, it is always unsafe to call a routine that needs an MVar you already have held open. you don't call exitWith by accident. There is always 'forkIO exitFailure' in any case.

You didn't show WithTemporaryExitHandler, which complicates things quite a bit.

it is uneeded, only a utility routine, I just didn't want to show the bookkeeping in the handler list to allow deletion of elements as it wasn't important to the scheme. any thread that wants to do bracket style cleanup just asks to be thrown an Exit exception and uses the standard 'bracket' etc.. routines.

Also, your implementation has a race condition - a thread might add another exit handler after the swapMVar.

that is why it is in a swapMVar loop, processing batch's of handlers. at some point, you just gotta accept that another thread didn't get its handler in on time, after all, if things were scheduled differently it might not have gotten there. mainly I wanted to make sure no handlers registered from within other handlers got lost, as those should run to completion being synchronously regiseterd from the handlers point of view.

I think we can probably agree on one thing: exitWith should raise an exception:

exitWith e = throw (ExitException e)

I disagree :) throwTo and throw should raise exceptions, exit should quit the program. though, perhaps we just need another function in the middle. AFAICT, what you are proposing is the same as mine but with forkIO being implemented as forkIO action = forkIO' action' where action' = do myThreadId >>= onExit . throwTo PleaseExit action I just want to have control as to whether that throw me an exception exit handler gets added and not have the implementation wait on my thread to clean up before it can exit if it has nothing special to clean up and might be deep in foreign calls. perhaps if there were just a flag on each thread saying whether they wanted to recieve exit message? though. I still don't like the idea of exitWith throwing anything, just feels really dirty. though, if there were a 'runExitHandlers' routine, what I want can be simulated by 'runExitHandlers >> exitWith_ foo'

This isn't inconsistent with your proposal, and I think it's unambiguously better. The top-level exception handler catches ExitException and performs the required steps (running handlers, calling exit_). As you said, you need a top-level exception handler anyway, this is just a small change to your proposal, moving the exit actions to the top-level exception handler.

but that means you have to wait until the thread with that top level exception handler becomes runnable. which could take arbitrary time if it is in a foreign call. I'd rather stuff be taken care of on the current thread (since we know we are runnable since we just ran exitWith), or on some new exit only thread. as if exitwith behaved as if it were called (forkIO $ exitWith) it just seems odd for your global system exit code to be hidden deep at the base of a certain threads stack somewhere. I don't mind so much exceptions being thrown everywhere to give things a chance to clean up, so much as the requirement we wait for it to fall off the distinguished 'main thread' before the program can actually quit. by default fork

...

3. simple rules. expressable in pure haskell. 4. can quit immediatly on a SIGINT since the exitWith routine runs on whatever thread called exit, rather than throwing responsibility back to the other threads which might be stuck in a foreign call. (unless you explicitly ask it to)

Don't understand this one - it certainly doesn't help with SIGINT in GHC.

when the signal occurs ghc sends a byte down a pipe, listening thread reads that and calls exitWith, exitWith calss exit_ which kills whole program immediatly, no need to wait for any other thread to do anything or even the foregin call running while the signal occured to complete. (if you don't want to) John -- John Meacham - ⑆repetae.net⑆john⑈