[Haskell-cafe] ANN: asynchronous-exceptions

[João Cristóvão]

Hi Roman,

One other question: in Michael's article, he also mentions the possibility of:
"Consider that, for some strange reason, we decided to asynchronously
throw an IOException to a worker thread"

Meaning that you can throwTo any exception asynchronouly, even if it
is not a SomeAsyncException. At least from what I gathered from (GHC
Head) throwTo code, this does not seem to be a restriction.

Thus, your module will work for any well behaved code that does the
right thing, and respects the SomeAsyncException superclass, but not
for other spurious asynchronous exceptions, right?

I'm just trying to frame the possible use cases of your library.
Thanks
Joao

2014-02-05 Roman Cheplyaka <roma at ro-che.info>:
> It works as expected.
>
> With GHC 7.8 it doesn't print the timeout exception.
>
> With earlier GHC it does (again, as expected, because the timeout
> exception isn't marked as asynchronous). In practice one should rarely
> want to use System.Timeout anyway (because of the overflow issue), and
> I'm going to patch one of the better timeout packages (such as
> unbounded-delays) to support asynchronous-exceptions.
>
> * Michael Snoyman <michael at snoyman.com> [2014-02-05 16:56:31+0200]
>> I don't think this package works as expected. Consider the following:
>>
>> import           Control.Concurrent
>> import           Control.Exception.Async
>> import           System.Timeout
>>
>> main :: IO ()
>> main = do
>>     timeout 1000000 $ do
>>         threadDelay 10000000 `catchSync` \e -> do
>>             print e
>>             threadDelay 10000000
>>     return ()
>>
>> The expected behavior would be that the timeout- an async exception- would
>> kill the thread delay, the catch would ignore the async exception, and the
>> program would exit. In reality, catchSync treats the timeout as a
>> synchronous exception, prints it, and delays once again. Compare this to
>> classy-prelude's catchAny, which handles the situation correctly, via the
>> technique I described in "Catching all exceptions."[1]
>>
>> In this case, the issue is that the timeout exception type is not
>> recognized as async, and a special case could be added to handle that
>> exception type[2]. However, I think the overall approach of determining
>> *how* an exception was thrown based on *what* was thrown is not tenable.
>>
>> [1]
>> https://www.fpcomplete.com/user/snoyberg/general-haskell/exceptions/catching-all-exceptions
>> [2] It's a bit difficult to do so, since IIRC the type is never exported.
>> But a hack using the Typeable instance- while ugly- is likely possible.
>>
>>
>> On Wed, Feb 5, 2014 at 1:28 PM, Roman Cheplyaka <roma at ro-che.info> wrote:
>>
>> > The links are:
>> >
>> > http://hackage.haskell.org/package/asynchronous-exceptions
>> > https://github.com/feuerbach/asynchronous-exceptions
>> >
>> > * Roman Cheplyaka <roma at ro-che.info> [2014-02-05 13:23:38+0200]
>> > > It is often useful to distinguish between synchronous and asynchronous
>> > > exceptions. The common idiom is to run a user-supplied computation
>> > > catching any synchronous exceptions but allowing asynchronous exceptions
>> > > (such as user interrupt) pass through.
>> > >
>> > > base 4.7 (shipped with GHC 7.8) will have SomeAsyncException type that
>> > > solves this problem.
>> > >
>> > > asynchronous-exceptions is a new package that serves two purposes:
>> > > * provide compatibility with older `base` versions that lack the
>> > >   `SomeAsyncException` type
>> > > * define convenient functions for catching only synchronous exceptions
>> > >
>> > > Roman
>> >
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe at haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>> >
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>