[IGSTK-Developers] Re: Further enhancements re: StateMachine::PushInput()

[David Gobbi]

Stephen R. Aylward wrote:

> Sorry that I've been out of it for several weeks - my life is now my 
> own (kind of).
>
> This is probably a really stupid question - but I am striving to 
> catch-up on things!   It seems like having an event push mechanism 
> poses challenges.

We're not saying that this "event push" mechanism is going to be used 
everywhere.  It is only going to be used in certain circumstances to 
allow an object with a state machine to reach a "safe" state before the 
observers that were set by the application were called.

Also, the event queue that is proposed here isn't one where one object 
puts events onto the queue, and then another object retrieves objects 
from the queue at leisure.  The same object that adds events to the 
queue is responsible for processing the queue as soon as it is safe to 
do so.  Everything is 100% deterministic.

> To overstate the challenges - isn't event queuing in a real-time 
> system "bad"?   A single tracker may feed multiple objects or multiple 
> trackers may feed a single object - each may involve a different mix 
> of priorities.   Say we have an ultrasound probe with an affixed 
> needle guide - perhaps the needle movement events will have a 
> different priority than the ultrasound movement events - even though 
> both come from the same tracker.  On the other hand, an object in an 
> image guided intervention may be tracked via image registration 
> initialized by multiple trackers - assuming image-based registration 
> isn't an instance of a hybrid tracker (but perhaps it is), then one 
> process may rely on multiple trackers.   Similarly, an object 
> collision detection process may need info from multiple trackers.

The main application thread is not going to be running in real time.  
Display is not going to be running in real time, either.  The only parts 
of the application that are going to be running in real time are 
specific threads doing specific duties that have to be done in real time.

> I guess these challenges can be overcome by having event queues that 
> are specific to each tracker/observer combination.  Is that that plan?

These "queues" are private to the object that generates the events, and 
are only there to allow an object can queue up events until the current 
state machine transition has finished (we're talking microseconds or 
nanoseconds here) before it calls the observers for those events.

You are thinking of the sort of message queue that an operating system 
uses to pass GUI events to an application, where the OS drops events 
onto one end of the queue and the application picks them up from the 
other end.  IGSTK isn't going to be using that sort of message queue.

 - David

> There is no need to respond if this is a truly bogus question...
>
> Stephen
>
>
>
> David Gobbi wrote:
>
>> Hi Luis,
>>
>> Taking this PushInput stuff up another notch, we also
>> need a way to push events.
>>
>> When a Tracker-derived class generates an event, we
>> don't want the observer to be called until after the state
>> machine has finished its processing.
>>
>> This will require an EventQueue class, and this class
>> probably belongs in ITK rather than IGSTK.
>>
>> EventQueue::PushEvent(const itk::EventObject &);
>> EventQueue::ProcessEvents(itk::Object &);
>>
>> Another possiblity is to queue the observers instead of
>> the events, but that would have to be built into itk::Object,
>> and would require the PushEvent() and ProcessEvents()
>> methods to be itk::Object methods.
>>
>> - David
>>
>> P.S. I'll add PushInputBoolean() to the state machine,
>> and next week Hee-su will modify the IGSTK code
>> to use it. Once it is done, Tracker coverage will
>> finally reach 100%.
>>
>> Luis Ibanez wrote:
>>
>>>
>>> Hi David
>>>
>>> That's a great idea,
>>>
>>> It certainly will help to clean up the code.
>>>
>>> Please feel free to make the modifications in
>>> the State Machine, or if you prefer we can make
>>> the changes on the State Machine from here.
>>>
>>>
>>>    Just let us know,
>>>
>>>
>>>        Thanks
>>>
>>>
>>>           Luis
>>>
>>>
>>>
>>>
>>> ------------------------
>>> David Gobbi wrote:
>>>
>>>> Hi Luis,
>>>>
>>>> Since the PushInput() method was added, we've added a lot of ugly 
>>>> code like this to the tracker:
>>>>
>>>>  if (result == SUCCESS )
>>>>    {
>>>>    m_StateMachine.PushInput( m_CloseTrackingSuccessInput );
>>>>    }
>>>>  else if( result == FAILURE )
>>>>    {
>>>>    m_StateMachine.PushInput( m_CloseTrackingFailureInput );
>>>>    }
>>>>
>>>> I have a very simple fix for this, which either me or Hee-su can 
>>>> implement:
>>>>
>>>>
>>>> m_StateMachine.PushInputBoolean(result, 
>>>> m_CloseTrackingSuccessInput, m_CloseTrackingFailureInput);
>>>>
>>>>
>>>> By adding a "PushInputBoolean" method to the state machine, the 
>>>> nasty if/else blocks that we recently added to igstkTracker can be 
>>>> removed.
>>>>
>>>> Does this sound reasonable?
>>>>
>>>> - David
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> IGSTK-Developers mailing list
>> IGSTK-Developers at public.kitware.com
>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>
>