Ah and now I've run into a slightly more serious problem... fibers don't like other fibers using "their" TcpConnections. That's going to be an issue, as there's several "broadcast"-like things that the server needs to do, and in fact not needing to do "safe" multithreaded code was part of the motivation for cooperative scheduling in the first place.

Is there a need for this restriction even when running in a purely single-threaded mode? Any easy way around it? I saw the broadcast example, but I'd rather not introduce explicit fiber message passing if I don't have to, since this didn't appear to be necessary on the old system.

I assume you're worried about certain yield points being at places where other use of the socket would cause issues, particularly stuff like closing the connection or similar. I suppose yielding when sending a particularly huge packet (if it does that) and then another fiber corrupting the data stream could be a concern as well, but in my old system there simply were no yields "in the middle" of sends... it would wait until it could atomically enqueue an entire packet before doing it.

Any suggestions? Am I forced to switch to message-passing and such even though I have no need for true multithreading/concurrency here?