[PyKDE] timer expiration routine execution?

[Phil Thompson]

On Thursday 13 February 2003 9:14 am, A.T. Hofkamp wrote:
> Hello all,
>
> In ym animation program, I have a timer that expires for every frame
> (currently about 5 times/second). The time expiration handler routine then
> moves the moving objects one frame.
>
> Which objects are to be moved is stored in a list.
>
>
> At the same time, data is read from stdin (in bursts). This input causes
> 'old' objects to be removed from the list, and 'new' objects to be added to
> the list.
>
>
> Obviously, the list is a shared resource here, i.e. it is accessed both
> from the input routine and from the timer expiration routine.
> I currently deal with this problem by stopping the timer (QTimer.stop()),
> reading and processing input, and restarting the timer.
> I am wondering whether this is sufficient. In particular, could it happen
> that at the moment I am calling QTimer.stop(), the timeout-handler routine
> is running?
> What happens then with the execution of the handler?
>
> The PyQt book doesn't say anything about this, the QT documentation states
> that "the timer stops" (I interpret this as "no new timeouts will occur
> after the call returns") but nothing about the execution of the handler or
> the processing of timeout-signals 'on their way' (i.e. nano-seconds before
> QTimer.stop() deactivates the timer, it expires, it posts a time-out
> signal, stops the timer, and returns to the read-routine).
>
> Is there anyone that can give me an idea on how to eliminate such potential
> disasters?

As far as I know QTimers are implemented on top of QTimerEvents - they are not 
like UNIX signals. In other words the Qt event loop will serialise access to 
your list for you - so long as you don't do anything that that causes Qt 
events to be processed while messing with the list. You don't even need to 
use QTimer.stop().

I think.

Phil