[Haskell-cafe] Re: Cleaning up threads

[Simon Marlow]

On 22/09/2010 09:51, Mitar wrote:
> Hi!
>
> On Wed, Sep 22, 2010 at 10:21 AM, Simon Marlow<marlowsd at gmail.com>  wrote:
>>   You could use maskUninterruptible, but that's not a good solution either - if an
>> operation during cleanup really does block, you'd like to be able to Control-C your
>> way out.
>
> So maybe this shows a need for maskUninterruptibleExcept (user
> exception for example).
>
>> So the only way out of this hole is: don't write long cleanup code that
>> needs to mask exceptions.  Find another way to do it.
>
> There is sometimes no other way. For example if cleanup requires
> extensive IO with robot on the Mars. It takes time for communicating
> in each direction and while waiting for the response it is really not
> a great idea that robot on the Mars is left in undefined state because
> cleanup function has been interrupted half a way doing its thing. Of
> course the protocol would be probably just that you send a message
> like "I am going away for some time, please confirm" and you wait for
> confirmation. So in most cases it will be OK even if the you do not
> really wait for confirmation, but sometimes there will be no
> confirmation and you will have to retry or try something else (like
> raise an alarm). (The point of such protocol message is that robot
> does not consume power trying to reach you when you are not there.)

Instead of thinking of this as "cleanup code" that runs in an exception 
handler, rather the program that communicates with the rover would have 
a state in which it is "recovering".  The exception handler moves the 
program into the recovery state, and then continues.  During the 
recovery state you can mask exceptions if you like, but you can also 
catch exceptions and handle them as you would in any other state.

The point I'm making here is that when cleanup code gets long and 
unweildy, it should become part of the main program logic rather than an 
exception handler.

> But yes, in this case I will simply use maskUninterruptible and also
> user should be blocked/masked from interrupting the cleanup. (He/she
> still has kill signal if this is really really what he/she wants.)
>
> Haskell great type checking is a great tool and help in mission
> critical programs, there is just this hidden side effect (exceptions)
> possibility built-in in language which has yet to be polished. In my
> opinion.
>
> This could be mitigated with "resume" from exception.

exceptions with resumption aren't exceptions, they're signals.  We can 
already do this in Haskell: you install a handler for the signal, and in 
the handler you decide whether to throw an exception to a thread or not.

> But this is only one part of the story I am trying to rise here. The
> other is that me, as an user of some library function, do not know and
> cannot know (yet) which exceptions this function can throw at me. I
> believe this is a major drawback.

You're talking about synchronous exceptions, which are a different beast 
entirely.  Wars have been waged about whether synchronous exceptions 
should show up in the types; IMO the Java folks lost here, and the 
general feeling is that the Java way was a poor choice (but it was hard 
to tell from the outset, they did it for the right reasons).

> Maybe what
> I am arguing for is that currently (with mask) you cannot say "mask
> everything except".

Perhaps, although that's quite tricky to implement.  Presumably you 
would have to supply a predicate (as a Haskell function), and the RTS 
would have to apply your predicate to the exception in order to decide 
whether to mask it or not.  What if the predicate loops, or raises an 
exception itself?

Cheers,
	Simon


> To answer Bas: I do not know how this should look like. I just know
> that I am missing Java's transparency what can be thrown and what not
> and its at-compile-time checking if you have covered all
> possibilities.
>
>
> Mitar
>
> P.S.: I am not really doing a remote control for Mars robot in
> Haskell, but it is not so much far off. Maybe it will even be there
> someday.