[racket] choosing channels or async-channels

On 2011-11-17 5:39 PM, John Clements wrote:
> If I'm reading the docs correctly, the principal advantage of the
> asynchronous buffers is actually their buffered nature, which makes
> it more likely that the messages will be received in the "right"
> order.  That, and possibly the fact that the buffer takes less memory
> than a stalled thread.

I've played with the code for async buffered channels recently. I reckon
you've mentioned two important advantages, but there are a couple of
additional things worth mentioning. Your points first:

 1. Ordering is preserved with async buffered channels
 2. Per-message overhead of a queued message is low

but in addition:

 3. Message ownership is transferred at point of send
 4. The queue is kill-safe

By (3) I mean that (thread (lambda () (channel-put c datum))) is part of
the sender's thread group, so if the sender is shut down before the
message is delivered, the message is "retracted" and no longer available
for receipt. When using an async buffered channel, the message is
transferred into the control of the channel's manager thread, which
generally resists being shut down (per the kill-safety paper [[1]]).
Even if the sending thread dies or is shut down, the message remains in
the queue for eventual receipt.

For (4), see [[1]]; the idea basically is that by carefully scoping the
lifetime of the manager thread, and having it do all the data-structure
manipulation, it becomes impossible for arbitrary crashes of clients to
leave the queue in an inconsistent state. (Synchronous channels form a
kind of primitive/atomic kill-safe communication mechanism, out of which
the larger ones are built.) Of course that's not an issue with your
thread-for-channel-put approach, though.

Cheers,
  Tony

[[1]] M. Flatt and R. B. Findler, "Kill-safe synchronization
abstractions," ACM SIGPLAN Notices, vol. 39, no. 6, p. 47, Jun. 2004.