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 On Tue, Aug 21, 2012 at 12:02 PM, James Cameron <qu...@laptop.org> wrote: > 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. > > 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 <qu...@laptop.org> 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. > > I don't understand what you would hope to achieve by calling .wait(). > > > 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 :) > > 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)." > > -- > James Cameron > http://quozl.linux.org.au/ >
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel