But together with this change it has become possible to read and write in parallel from different tasks. So a broadcasting facility could now be implemented similar to this (untested), using the new message passing facilities:
Hmm ok, well that was what I was originally doing anyways. I assume this means it's now safe to write to a TcpConnection from a fiber that doesn't own it?
I implemented something similar (didn't bother with the writer task to start with and just write directly to the other TcpConnections where necessary); unfortunately I'm having the issue that it appears that somehow the socket is now getting into a weird state where it doesn't detect disconnects while waiting in blocking functions like read(). Strangely, if I switch it to do a busy wait loop on dataavailablefor_read() around the read() it never even goes inside. But yet stream.connected remains true even when the client application has long since disconnected and even quit... this is all with the libevent2 backend.
Not sure if this is something you may have seen, but any suggestions on how to debug would be helpful.
My apologies for the breakage, it was unfortunately not avoidable in this case - but for the better, I think.
Meh, it's ok. I knew the rawYield thing was a temporary solution at best. I just need an alternative now...