Proposal: Control.Concurrent.Async

[Chris Kuklewicz]

I think we should distinguish two cases for "cancel".  I emphasized one case and
rambled a bit in my previous message.  I hope this is clearer.

On 2012/06/12 11:33, Simon Marlow wrote:
> I appreciate that sometimes cancel may block and that you may want a
> non-blocking cancel, but I don't think that should be the default.
> 
> Firstly, the user might find it surprising if when withAsync has returned, the
> Async still performs some more operations (that are not inside an exception
> handler).  I think it's an important guarantee that this doesn't happen -
> otherwise, what can you say with any certainty about the behaviour of withAsync?

I totally 100% have always agreed with that -- for withAsync.  That is the
correct semantics to minimize surprise when sequencing the two IO actions.

But... you also include "race" and "concurrently" where the user has explicitly
asked to go crazy with lots of non-deterministic interleaving.  It may be that
some are talking to blocking FFI things and thus it may be nice to have a
version of these that calls asyncCancel internally:

> Secondly, asynchronous cancel is easily implemented by the user, as
> 
>   asyncCancel = async . cancel

If a user wanted race + asyncCancel then she could copy-paste your module's code
with the changes.  This is certainly something the user could do -- and the
documentation can point out when it would be needed.

I hope I have been clearer.  I was not being crazy and says withAsync needed
asyncCancel.

-- 
Chris