Hi Mats,

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.

In the approach I was describing, yes, each callback can be bound to a different channel.

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.

It sounds like you would prefer that both go to the same thread in this case? Again, either would be supported using the design I am proposing.

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.

I suppose it always will depend on what happens in the callback whether it is best to have lots of threads banging away or serialize them or plod along with a pool of 1/CPU. All are valid, but a library would be unable to chose which is best. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com