[Haskell-cafe] ANN: asynchronous-exceptions

[Michael Snoyman]

I like the idea of renaming the module to reflect this concept (I'm fine
with either Inner or Enclosed), but leaving the function names themselves
as-is.


On Thu, Feb 6, 2014 at 2:12 PM, João Cristóvão <jmacristovao at gmail.com>wrote:

> Thanks Roman and Michael for the latest clarifications:
>
> I had indeed forgot the case where a thread runned in catchAny spawn
> child threads that kill their parent.
>
> > But given how overloaded the term is, I'd be in favor of coming up with
> a new term to represent what these catch functions are intended to do.
>
> The word currently in my head is 'inner', although Roman's suggestion
> of 'enclosed' looks fine too. Internal is also correct, but as it is
> regularly used to denote a package internal functions, it may lead to
> confusion.
>
> What these functions (classy prelude/my library spin-off) do is run a
> computation, isolating it from the calling thread (through async) and
> catching all inner exceptions (of either synchronous or asynchronous
> type, raised by either throwIO or throwTo instructions _present
> somewhere inside that computation_, or by the RTS but once again
> affecting only that computation, not the calling one.
>
> The calling one is thus 'free' to receive asynchronous exceptions in
> the meantime (the execution of the inner computation).
>
> Thus, I propose either:
>
> Control.Exception.Inner / Control.Exception.Enclosed
>
> And/or, possibly also rename the functions to something like:
>
> catchAnyInner / catchAnyEnclosed
>
> Although I do not like this last option so much, the function name
> gets too long, but that's a personal preference.
>
>
> What do you think?
> João
>
> 2014-02-06 Michael Snoyman <michael at snoyman.com>:
> >
> >
> >
> > On Thu, Feb 6, 2014 at 8:17 AM, Roman Cheplyaka <roma at ro-che.info>
> wrote:
> >>
> >> > Am I getting this right?
> >>
> >> Not quite.
> >>
> >> The enclosed computation may get asynchronous exceptions whatever
> >> definition of 'asynchronous' you use -- the exact one (by throw method)
> >> or the approximate one (by type).
> >>
> >> Just a couple of examples:
> >>
> >> * The thread may catch an async exception from the RTS (such as
> >>   BlockedIndefinitelyOnMVar or StackOverflow)
> >> * The thread may spawn other threads, passing its pid to them, and one
> >>   of its children may eventually kill it
> >>
> >> So I'd say this method allows to catch any exceptions "related" to
> >> the computation, synchronous or asynchronous. It is this "relatedness"
> >> that is enforced by running it in a separate thread.
> >>
> >> Roman
> >>
> >
> > I definitely think this is important to get our terminology right. A lot
> of
> > the scariness of async exceptions likely spawns from the fact that we use
> > the same term to refer to a number of very different cases. Let me give a
> > crack at breaking down exceptions:
> >
> > * An exception with a synchronous type (e.g., IOException) thrown via
> > throwIO. This is the most synchronous of synchronous exceptions.
> > * An exception with an asynchronous type (e.g., UserInterrupt) thrown via
> > throwIO. There's legitimate room for debate as to what we should call
> this.
> > For my purposes, I'd want to call it a synchronous exception.
> > * An exception with a synchronous type thrown via throwTo. Similar to
> > previous bullet, but I'd consider this asynchronous.
> > * An exception with an asynchronous type thrown via throwTo. This is
> solidly
> > an asynchronous exception.
> >
> > Then we have some more interesting questions:
> >
> > * What *is* an asynchronous type? By including
> BlockedIndefinitelyOnMVar, it
> > seems like you're defining it to include any exception generated by the
> RTS.
> > However, I'd consider it a synchronous exception: it is generated in
> direct
> > consequence of performing an IO action. It just happens to be generated
> by
> > the RTS instead of via some library talking to the filesystem.
> > * What happens if an async exception is caught and then rethrown? Has it
> > transformed itself into a synchronous exception? That's a tricky
> question,
> > and likely depends on the exact manner in which is was caught.
> > * What happens if a function utilizes some form of asynchronous exception
> > mechanism to affect its behavior? The prime example of this is
> `timeout`, or
> > better, the `asyncTimeout` function I displayed above. Internally to that
> > function, I think that's an async exception. However, for a *caller* of
> that
> > function, the behavior is actually synchronous: there was no notification
> > from the outside world changing the behavior of this function, it simply
> has
> > the possibility to terminate by throwing a Timeout, the same way a
> function
> > may terminate by throwing an IOException.
> >
> > That last bullet is crucial to the question of whether classy-prelude's
> and
> > João's catching functions are asynchronous or not. But given how
> overloaded
> > the term is, I'd be in favor of coming up with a new term to represent
> what
> > these catch functions are intended to do.
> >
> > Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140206/534dfadc/attachment.html>