James, Yes. Only one thread ACTUALLY executes on at any time on a uniprocessor system. That is logical. But the thing is.. I am not at all wanting to speed up anything .. :P :P I am wanting to solve an issue, which in the present case seems possible ONLY by using two threads. My intention is to somehow have GUI updates in a synchronous manner, and not rely upon "gobject.idle_add", which would have to have dividing a long workflow into many sub-parts, and chaining these sub-parts through "gobject.idle_add". This is EXTREMELY painful, especially when one needs to do it on an already existing codebase. So, the two-thread workflow would make that easier. And yes, only one thread will execute any time; in fact, my suggested workflow takes advantage of this only-one-thread-running fact :D At the same time, I also think that there is no easy way to do what I want. At least not without hacking onto the python-core code (event loop implementation). Thanks and Regards, Ajay <div class="gmail_quote"> On Tue, Aug 21, 2012 at 12:02 PM, James Cameron <<a href="mailto:quozl@laptop.org" target="_blank">quozl@laptop.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> First, learn that on a single processor system, only one thread actually executes at a given time, so if you think you have more than one thread of execution, you're wrong and you really only have one. As soon as you expand the time for sampling, yes, more than one thread, or process, may execute. In this situation, threads are an abstraction which distorts reality. <div class="im"> On Tue, Aug 21, 2012 at 11:33:55AM +0530, Ajay Garg wrote: > Thanks James for the reply. > > > On Tue, Aug 21, 2012 at 3:47 AM, James Cameron <<a href="mailto:quozl@laptop.org">quozl@laptop.org</a>> wrote: > > On Tue, Aug 21, 2012 at 12:11:13AM +0530, Ajay Garg wrote: > > So, is there a way to have the code always in-order; in other words, > > have the GUI updates absolutely synchronous? > > No, not without waiting for the update to complete, and if you do > this, the code runs very slowly. > > (When there is only one CPU, only one process can execute on it at a > time. The updates are placed in a pipeline to the display, and the > display process runs them as soon as it is practical to do so. If > your process does not release the CPU, then your process will likely > continue executing until it hits something that will cause it to > release. It is better to be specific and use idle_add to release.) > > > Right. > > Now, from what I believe, that there is just one "main" thread, that is > responsible for running the "normal, backend" code, and the same "main" thread > does the GUI updates (of the events present in the display pipeline), when it > has nothing more to do with the "normal, backend" code. > > This also means, that doing something like > > main_thread.wait() > > would be idiotic, as that would stall the GUI updates as well. </div>I don't understand what you would hope to achieve by calling .wait(). <div class="im"> > So, does there exist a method, that could cause doing the GUI updates in a > different (other than the "main" thread) ? > If yes, that would solve the issue, as the following would then be feasible :: > > <main thread> logic statement 1 > <main thread> spawn a new thread, and pass the GUI-update event to > it | > <main thread> "joins" on the new > thread | > > | anywhere in this interval, the new thread performs the GUI update > > | > > | > > new thread terminates > <main thread> logic statement 2 > > > > At first, it seems that the "<main thread> spawn a new thread, and pass the > GUI-update event to it" step is trivial. > However, the thing to note that in a default python configuration, all GUI > update events are scheduled in the context of the main thread. > > So, only if the GUI update events could be scheduled to be processed in a > custom thread - that would be awesome !!! > > > Please let me know if any such method exists :) </div>No, I don't think so. It is an event loop implementation only. For more information, google "Threads Considered Harmful", and check out John Ousterhout's paper "Why Threads Are A Bad Idea (for most purposes)." <div class="HOEnZb"><div class="h5"> -- James Cameron <a href="http://quozl.linux.org.au/" target="_blank">http://quozl.linux.org.au/</a> </div></div></blockquote></div>