The Signal is usable in two ways:

  1. The normal way, wait()ing for the signal to be emitted. Multiple fibers can wait (block) for the signal and all will continue when the singal is emitted.

Ok so this is effectively what a TcpConnection will do when I do a "receive" for N bytes until that many bytes are available? So no other signals than the one it is waiting on will wake the fiber at that point, correct? That's actually the desirable behaviour I think. 

After `rawYield()` continues, the event that caused this can be indirectly determined by asking the TCP connection if data is available, or by asking the `Signal` if the emit count was increased.

Alright, that makes sense. I implemented this model with a simple queue of outgoing packets. The main loop basically checks for incoming data, and consumes it all if any is available (it'll block waiting for a full packet to come in, etc). After that if there is anything pending in the send queue it will flush that all out (again, presumably blocking if the socket send buffer fills) and then do a rawYield. Basically the same model as the broadcast example, except I use one signal per client which fires when anything is added to that client's queue, as not all cross-client messages are broadcasts.

Seems to work properly, so modulo figuring out a policy for maximum send queue size, etc. I'm happy :)

I consider this just a temporary compromise to make this kind of bidirectional braodcasting work at all, with the danger that it relies on the way events are handled internally, which might (although probably not) change in the future or between different back ends.

Right, I'll put a big warning in my code that it might break in the future :) Presumably if it does break, the broadcast example will be updated with the new "best known method"?

Sound good! Btw., it's still at least half a year off until I'll get to this, but I also plan to use vibe.d in a game/simulation engine... currently I'm held up by a lot of other stuff, but it would be a dream to be able to work on this kind off stuff again :)

Cool, yeah it's a lot of fun :) This project is a volunteer "spare time" type of thing for an old game, but doing it in D with fibers and lots of clever mixins (for stuff like swapping endianness of structures) has made the code extremely concise and fun to play around with!

Thanks for all your help. I think everything is pretty much up and running now in terms of what was already working. Next is to tackle the HTTP stuff and make it interact nicely with a web server (as a client, for now).