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
acrobatics in
order to read the same connection in one fiber but write to it
another. In, reads are handled by callbacks, and all
writes are
delayed (data is queued and sent when the socket loop says the
socket is
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
same thread).

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.

Reply via email to