Fwd: hope to see some blog posts about Async

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

This is a really interesting variant on Lwt cancellation that Twitter use in 
Finagle. Since we're having so many problems with the Lwt approach, I suspect 
moving towards a monitor-style cancel propagation is sensible.

-anil

Begin forwarded message:

> From: "marius a. eriksen" <marius@xxxxxxxxxx>
> Subject: Re: hope to see some blog posts about Async
> Date: 20 January 2012 19:21:53 GMT
> To: ocaml-core@xxxxxxxxxxxxxxxx
> Cc: Stephen Weeks <sweeks@xxxxxxxxxxxxxx>
> Reply-To: ocaml-core@xxxxxxxxxxxxxxxx
> 
> Cancellation is really tricky to get right. I think the correct choice
> in many circumstances is to not support it at all, and instead use
> some other mechanism when needed.
> 
> Concurrent ML presents a very nice solution to threads that require
> cancellation: event synchronization is atomic. However, they don't
> compose as well as futures do: For example, synchronization isn't
> transitive across multiple processes.
> 
> What we ended up doing in Finagle[1], which I think worked out very
> well, was to not support cancellation, but rather a cancellation
> *signal* that flows in the opposite direction from value propagation. The
> signal is level triggered, and any interested party can listen to it.
> The propagation composes in the expected way (opposite in direction
> from the value).
> 
> In other words:
> 
>  let composed = foo >>= (fun _ -> bar)
> 
> propagates cancellation signals on `composed' to `bar', just like values
> are propagated from `bar' to `composed'.
> 
> You can then listen to the signal (in scala:
> 
>  on_cancellation bar (fun () -> (* whatever you like *))
> 
> The nice thing about this approach is that only the updater of the
> value need worry about cancellation, and we can use this to guarantee
> that there's *only one update path*. This actually solves all of the
> try … catch problems, because if there is cancellation, the signal
> makes it all the way to the updater of the future, and *it* can decide
> what to do. We introduced cancellation in this way about 6 months ago,
> and there have yet to be any bugs surfaced from it.
> 
> btw: if Pipes weren't buffered, they'd essentially be CML's channels
> 
> [1] https://github.com/twitter/finagle
>