Don G wrote:
Yes. The "generic async library" I keep mentioning is where this is handled w/o the user A) being called in the wrong thread or B) the user manually doing any posting.
Sorry if this is covered somewhere, but would the user have any say in what goes down if an async_read and an async_write on the same socket complete more or less simultaneously? (In the presence of multiple worker threads) Sometimes the application logic calls for serializing the callbacks and sometimes it would be better to allocate each callback to a different thread, possibly allowing them to run in parallel. I have recently had to deal with synchronization/starvation issues caused by this kind of design (simultaneous pending async_read and _write on the same socket) in an application using Windows' OverlappedCompletionPort mechanisms. If the callbacks for the read and write operations both race to lock the same resource (e.g. the session object mutex), one of the completed operations will obviously have to wait for the other. This wastes one precious working thread, because it is just sitting there waiting while it could be serving other connections instead. I tried to alleviate this waste by transferring the "completion-token" to the first thread. Once the first thread was done with its first callback (e.g 'on_read'), it would proceed to handle the transferred callback (e.g 'on_written') before returning itself to the pool. This made the situation much better, but somehow tended to cluster related operations, since each thread would do comparatively more work on one socket before allowing another session's callbacks to be processed. It made better use of the threads, but possibly on the expense of fairness. Mats