On samedi 22 novembre 2008, David Ripton wrote:
> 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.
I'll try to run the thread test scripts...
> > 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.
Thanks for all these tips. I think I will use you queue system, that sounds
good :o)
--
Frédéric
http://www.gbiloba.org
_______________________________________________
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
