On 2008.11.22 11:28:22 +0100, Frédéric wrote:
> I have some troubles with threads in my Papywizard app.
>
> During the shooting process, I launch a thread which iterates over all
> shooting positions, and control the hardware to move the panoramic head,
> and trigger the camera.
>
> Right after this thread is launch, I periodically execute a function from
> the GTK lop, using gobject.timeout_add(). In this function, I read some
> variables of the external thread to refresh the GUI. The user can also
> interact with the GUI during the shooting process, to pause/stop it.
>
> All works fine on my PC (running linux), but I experience several problems
> on maemo. For example, some part of the GUI are not correctly refreshed
> the first time I launch the shooting process. If I stop it, and retry, all
> works fine. Another issue is that I can send user action at wrong moments.
> I think this a related to the lower speed execution of the application,
> showing me some wrong-codeed things in my app.
>
> So I need to add some robust inter-threads sync mecanisms, to ensure I
> can't trigger actions at the wrong place. I tried to use the Event object
> from the standard threading module, but it does not work under maemo
> (while it works fine on the PC) :o(
If threading.Event doesn't work on maemo, I worry about whether the
other basic locking primitives are broken too. Try running
test_thread.py and test_threading.py from the Python source tree. If
basic locks are broken then threads are completely unsafe, and you'll
need to either fix them or use a different concurrency model.
> So, what other mecanism should I use to sync my threads? Is there a
> GTK-based macanism?
Assuming threading.Lock works on maemo, I suggest Queue.Queue, from the
Python standard library.
The idea is that you don't share mutable objects across threads.
Instead, you pass safe messages composed of tuples of immutable value
objects (strings, ints, etc.) across queues. Then your threads can't
corrupt each other's mutable data because they can't even see each
other's mutable data. And you won't get deadlocks because you're not
using lots of locks, just one per queue, which is inside proven library
code. And you can't read data at a bad time (like in between updating x
and y of the camera's position coordinates) because the other thread
knows when to safely put its data onto the queue.
In your case I think you'd want two queues, one carrying commands from
the GUI thread to the external thread (e.g. ("move_camera", 3, 4, 5))
and one carrying status the other way (e.g. ("flashed", "Bulb3",
1227370225.247529)). And then each side has a loop that periodically
does a non-blocking read from the appropriate queue and takes the
appropriate action if it finds something there.
--
David Ripton [EMAIL PROTECTED]
_______________________________________________
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
