Synchronous Channel?

[eulerfx]

A channel akin to CML / Hopac with the following operations:

type Ch<'a>

val create : unit -> Ch<'a>

val createFull : 'a -> Ch<'a>

/// Creates an async computation which produces a result when a value is available.
val take : Ch<'a> -> Async<'a>

/// Creates an async computation which completes when a matching take operation is available.
val fill : 'a -> Ch<'a> -> Async<unit>

What should it be named? AsyncCh could be misleading because the semantics are synchronous, but Async is used for the notifications.

[vasily-kirichenko]

Why not just use Hopac? For this, for streams, for async events and so on, so on.

[eulerfx]

Could do, but then do we create a dependency on Hopac from here? Also, I haven't benchmarked, but it seems the benefit of Hopac channels might be outweighed by the cost of converting back to Async.

I think that adding some of the cool stuff from Hopac into this library will serve as a sort of gateway to Hopac as a more powerful alternative (pun intended) to Async.

[polytypic]

Performance wise it depends.

First of all, I think the current implementations of async <---> hopac conversions in Hopac are not optimal. I actually worked on optimizing one of them last night, but my initial approach turned out to be wrong (slow), so I will be looking into it again at some point.

Hopac is roughly 2 - 3 times faster in executing basic straight line code and much faster (5 - 50 times) in many other basic operations (message receive & spawn new job). The way I've used choice streams, for example, basically with all the stream processing (choose, debounce, map, combine latest, distinct until changed, ...) in Hopac and then some async on main thread, the cost of doing the Hopac -> async on main -> Hopac hop is simply insignificant. Honestly, I would be surprised if doing the whole thing with async (especially if asyncseq would offer comparable non-ephemeral semantics) would be within a factor of ten in terms of performance.