[Sugar-devel] Is there a way to purposefully do synchronous GUI updates?

[Ajay Garg]

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 <quozl at 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 <quozl at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120821/3185a2c0/attachment-0001.html>