Thanks for the comments Andrew... this thread piqued my interest.. see
inline comments below.
On Tue, Sep 14, 2010 at 7:47 AM, Andrew Stitcher <astitc...@redhat.com> wrote:
> >From the description it seems that you are asking about the RDMA
> AsynchIO state transition. You should have said that as part of the
> description as it is entirely different from and other part of the IO
> system of qpid.
Having multiple AsynchIO classes is confusing, IMHO, even though they
are in separate namespaces.
>
> On Mon, 2010-09-13 at 15:04 -0700, Danny Guo wrote:
>> Hi all,
>>
>>
>> Is there a simplistic way to understand the state transition? I got confused
>> with the oldState, newState and “action”.
>
> I find that drawing a state diagram helps me to understand what's going
> on - I find I need to do this about every 6 months (and I wrote the code
> in question).
I also found this code difficult to read and understand. It is not
the idea of spinning on an atomic interlock (state) variable that is
confusing to me, but digesting the state semantics and actions you
take based on transitions.
Maybe someone should contribute a dot (graphviz) file of the state
transitions and check it in wherever design docs go.
We could just use pthread_spin_lock() around your state transition
case statement, instead of spinning on the primitive compare and swap.
Not sure how much more readable that would be, but it happens to be
more my style. ;-)
<snip>
> The entire purpose of this state machine is to arbitrate between calls
> to dataEvent() and notifyPendingWrite() which can happen on different
> threads at the same time.
Segue to a related question I have... Can you help me understand, or
just point to docs/code, the threads involved here?
The upper layers ("app") call notifyPendingWrite() from whatever
thread they want. dataEvent() gets called from the poller thread. Is
it correct that there is typically only one poller thread per
Blah::AsynchIO instance?
Where does the --worker-threads=N arg to the CPP qpidd broker come into play?
Finally--perhaps a can of worms-- but why does notifyPendingWrite()
exist, instead of just writeThis(). Is this part of the "bottom-up
IO" design? I feel like having the app tell us it wants to write (so
call me back) is more complex than just having a writeThis(buf)
method.
Thanks again,
Aaron
<snip>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
