Steve Huston wrote:
Hi folks,
I have a question for the C++ broker folks that has arisen while
debugging a problem in the Windows code.
In my case, there are two threads involved:
1. Processing a SessionDetach received from a client. This ends up
deleting the session state, and in so doing, ends up in
SemanticState::cancel() which removes a task from outputTasks.
2. Processing the completion of writing the SessionDetached back to
that client. This ends up calling AsynchIOHandler::idle() and a few
frames up, AggregateOutput::doOutput() which walks through outputTasks
- the same outputTasks that are being manipulated in thread 1.
There is no guard on the manipulation of outputTasks here...
Is there some implicit ordering designed in here that I may be
violating?
The code is designed under the assumption that a connection will be
processed by a single thread at any given time. The only call that is
allowed to be concurrent is the the OutputControl::actvateOutput()
method (used to request that an otherwise potentially idle connection be
given use of a thread through OutputTask::doOutput().
So calling AggregateOutput::doOutput() on one thread while processing an
incoming frame on another thread would (under the current assumptions)
be invalid and would be expected to fail.
