[Haskell-cafe] Re: Cleaning up threads

[Mitar]

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.)

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.

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. Code behavior should be transparent
and types do help here. But (possibility of) exceptions are hidden. To
be prepared for any exception (even those not yet defined at the time
of writing) in code is sometimes a too hard requirement (you are
writing about async-exception-saftiness). Especially because for some
exceptions you could want some behavior and for some other. Maybe what
I am arguing for is that currently (with mask) you cannot say "mask
everything except".

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.