|
Boost Users : |
From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2007-08-08 17:36:44
>>> I ended up implementing timeout support with a WM_TIMER handler in the
>>> parent of the state machine class. ...
>>
>> Does the WM_TIMER handler really add the event to the queue of the
>> state_machine subclass object? If so, then you might have introduced
>> a race condition. WM_TIMER handlers are called in a dedicated thread,
>> right?
>
> From my understanding of the documentation of SetTimer and my use of it,
> everything should be working from the same thread (WM_TIMER messages are
> posted to the main thread's message queue, where they are processed while
> the thread is idle). So, I don't think there's a race condition.
Ahh yes, good old WM_TIMER... You are of course safe as long as only the
main thread calls state_machine::process_event().
>>> and awkward instancing of the event.
>>
>> I don't understand. You mean the special constructor you have to add
>> to the state, right?
>
> Well, that, but more importantly, the cast inside of the post_event.
> Making calls to post_event from a constructor/enter seem like a fairly
> typical use case.
Hmmm, with "cast" you mean the call to the context<> function? Have you
noticed that there's a simple_state::post_event function, ...
http://www.boost.org/libs/statechart/doc/reference.html#post_event1
... which you are allowed to call from a ctor of a state subclass?
HTH,
-- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net