Am 05.06.2015 um 02:01 schrieb Vladimir Panteleev:
On Thursday, 4 June 2015 at 21:10:13 UTC, Sönke Ludwig wrote:
I don't know how things are now, but when I tried to move to
(which was several years ago), you had to do some strange
order to read the same connection in one fiber but write to it
another. In ae.net, reads are handled by callbacks, and all
delayed (data is queued and sent when the socket loop says the
writable), which means there is no contention and you can
"write" to any
socket from anywhere in the program (as long as it's in the
This has been solved in the meantime. Reads and writes can now occur
concurrently in different fibers.
Good to know. What about writing from multiple fibers to the same
connection (e.g. an IRC client that needs to send PINGs from a timer
fiber and also announce events coming from other fibers)? IIRC a
connection's input/output streams needed to be explicitly associated
with a fiber?
You'd need to use a TaskMutex to serialize access to the connection in
that case, but no explicit ownership management is needed (that has
actually been removed from the API back then). I was thinking about
making this the default behavior, though (instead of throwing an
assertion error for mutual write access). After all that's what happens
with normal blocking I/O and threads, too.