Thus, you'd have to create a global/static Task[string] aa that your connections mutually know about
Right, I should have been clear... this is effectively what I'm already doing and it "works", but it's inelegant IMO. My follow-up here was basically to point out that global data - and indeed closures/delegates themselves - don't attempt to be "safe" in terms fo data races, but yet the concurrency interface in D (and thus vibe mirrors it) makes an ill-fated attempt to do it.
So yeah, I can basically bypass the aliasing analysis by working with shared global/stack data here and sync the fibers appropriately, but I argue that shows a bit of a weakness of the current concurrency model. I should be able to just pass stuff across in messages, but the attempt at making it "safe" makes the interface largely useless syntactic sugar with very little additional expressive power over a simple manual event.
Anyways this isn't a critique of vibe so much as D concurrency, but I thought it worth bringing up the discussion in the context of vibe since there are a large number of use cases that expose the issues.
(And again, yes I get the whole attempt at thread safety and vibe you don't have to be multithreaded yada yada, but I maintain that even in a multithreaded situation it does far more harm than good.)