[Gnumed-devel] re: wxCallAfter

[syan tan]

Karsten wrote:
> one inbound-data-avail gmDispatcher-connected listener in
  the main thread receives such events and issues a
  wxCallAfter(gmScriptingProxy.process_next()) which gets us
  out of the quagmire

sorry, finally read this ,I hope , correctly, the third time.
that sounds ok, but it makes the thread unsafety issue just 
specific for the extra scripting listener thread . 

Maybe have  a wxCallAfter( dispatcher.dispatchHeldEvents()) 
so then every event type gets the same deal. 

 On the other hand, queuing dispatcher messages means you can't write something 
like:

dispatcher.send(patientChangedEvent) //this becomes asynchronous
updateUI() // just in case the listeners on the patientChangedEvent 
           // didn't do ui updates on receiving the event.

and expect updateUI() to do anything.

- another issue might be , what if listeners can be added or removed
more often than just at application initialization? Isolating the 
thread unsafety handling to a specific listener wouldn't solve a problem
where the dispatcher is iterating through its list of listeners and the 
list is changed, unless the weak reference map operations used by gmDispatcher 
are thread safe (e.g. the iterator iterates a COPY of the list
when it is created ( does it , in Python?) ).

- sorry for the rant, but Karsten's proposed feature is quite interesting.