Sorry for the late answer... On 3/29/07, Ken McIvor <[EMAIL PROTECTED]> wrote: > On Mar 28, 2007, at 6:03 PM, Antonino Ingargiola wrote: > > On 3/28/07, Ken McIvor <[EMAIL PROTECTED]> wrote: > >> You should probably do the acquisition asynchronously by running it > >> in a separate thread. > <snip> > > > > That's exactly what I'd like to do. The problem is that if I run > > gtk.main() (the gtk main GUI loop) in a separate thread the program > > stops until I do something on the GUI (for example passing the mouse > > on it). > > Does it do this if you run gtk.main() in the main thread (e.g. the > interpreter prompt) while doing something else in a background thread?
Good idea. I will try it next time I'll do something with GUI and thread. > > My understanding so far is the following. When the function > > that execute gtk.main() is executed, python doesn't switch thread > > until either 100 bytecode instructions are executed or since an I/O > > (potentially) blocking operation in executed. > > I think you're more or less correct but are unaware of one important > factor. Here's my understanding of how multithreading works in > Python... > > Thread switching is controlled by something called the Global > Interpreter Lock, which is implemented in an abstract way on top of > an OS lock/mutex object. Only one Python thread runs at a time > because the Python interpreter requires a thread to hold the GIL > before it can execute bytecode instructions. The running thread > holds the GIL while is executes 100 instructions. During this time > other Python threads block waiting to acquire the GIL. After it has > executed its 100 instructions, the running thread releases the GIL > and then attempts to reacquire it. The OS ensures that things are > fair by preventing one thread from reacquiring the GIL over and over > again when other threads are also waiting for it. > > Python doesn't actually detect you do something that will block the > thread, like an I/O operation. Instead, the C code implementing an I/ > O operation like file.write() releases the GIL before performing the > operation. This allows a different thread to acquire it and run some > more bytecode instructions while the first thread performs its I/O > operation. Thanks for the explanation, it's clear now :). > > BTW, the timer idea is good and eliminates the need to call > > asynchronously the GUI thread to update the plot, which seems (the > > latter case) not very simple to do. > > Yep. It's impossible to inject arbitrary code into a Python thread; > the thread has to figure out what it's supposed to do by periodically > polling something or retrieving some kind of message by blocking on a > queue. Blocking on a queue isn't an option for the GUI thread. > > You might be able to trigger Gtk signals from a separate thread but > in my experience tricks like that can be, well, tricky. Good to know that this way is too tricky (at least). > > The last think I'm not yet able to do is to update the colorbar to > > autoscale with the new incoming data. The the script that follows > > tries to update the colorbar too but it does not work (on matplotlib > > 0.87 at least). > > I have no idea if this will help, but you might need to call > AxesImage.changed() after calling AxesImage.set_data(). That doesn't help :(. I'm not jet able to update the colorbar once the image has changed. I will open a new thread to discuss this problem. > Ken ~ Antonio ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
