Boost logo

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