Re: Continuing the saga Non-Blocking GUI developement

["Paul Davis" <pjdavis engineering uiowa edu>]

Melvin,

Wow, that email was quite a bit longer than I thought.  And I managed
to not even include the gtk list in the reply.

Any, I just realized the title of your thread is Non-Blocking GUI development.

Going from completely abstract to actual implementation you're not
doing something like this:

while( true )
{
  status = read( fd, my_buf, my_buf_size )

  if( status == 0 && errno != EAGAIN )
  {
      throw some error ;
   }
  else if( status > 0 )
  {
     process_some_data( my_buf, status ) ;
 }
}

Paul

On 1/25/07, Paul Davis <pjdavis engineering uiowa edu> wrote:
> On 1/24/07, Melvin Newman <zexelon gmail com> wrote:
> > Paul:
> >
> > Thanks for the quick response. From what I have seen so far, the desktop
> > remains active, it does however slow down but that I think is more a factor
> > of several other monitoring programs I have running in the background.
> > Unfortunately I can not  give up control from my processing function as it
> > has to communicate in near real-time (transmitting user input).
>
> If you're gui is frozen, where is it getting user input to send?
>
>  There are
> > times where it is idle however, so this would be a good time i assume to
> > update the gui, how do I go about telling the GUI to update though?
> >
>
> You don't 'tell' the gui to update. You 'let' it update. When your
> worker thread isn't doing something, you put in into a state so that
> its not using CPU resources.  I'm not familiar with the gthread api,
> but the most common example of this the producer/consumer model for
> threaded applications.  Using condition variables to wait for input.
>
> It sounds like you need to look at what your thread is actually doing.
> Basically, if you're not doing some extremely complicated numerical
> processing or say traversing graphs with hundreds of thousands of
> nodes, there should be no reason why you can't maintain a responsive
> GUI. (And even then, with a pretty good implementation you should
> still be all right)
>
> When you say that your processing thread needs to respond to user
> input in near real time there are two things you should consider.
> First, if this is a mission critical showstopping app, would it be
> worth it to use a real time os. Second, when you say real time do you
> actually mean something more like "I want the user to see changes
> right away so he or she knows things are working correctly." They may
> not seem entirely different, but they're a couple orders of magnitude
> apart. Ie, real time means planes crash and people die if the deadline
> isn't met. The latter is more like, people that use my program get
> pissed cause its slow.
>
> In the first case with deaths as a serious repercussion of a missed
> deadline, my first guess is that you wouldn't be asking on this
> particular list about threading. So I'm gonna go with the pissed off
> users theory.
>
> I think i read or heard somewhere that people don't start getting
> pissed until actions they perform (button click) have more than a
> third or half second delay until visual confirmation that the action
> has been recieved.  Either way, thats a long time in the world of
> gigahertz computers. You're looking at minimizing latency between when
> I click button x and see the webcam guy do a hand stand.
>
> Generally, with correctly written software, this limit isn't reached.
> Most things people do with computers aren't extremely computationaly
> intensive (no scientific studies to back this up, but really how much
> power does it take for me to surf diggdot, im and write this email at
> the same time?)  In a slightly unrelated vein, i saw a discussion once
> about how software developers have failed to keep pace with
> tecnological advancements. Basically, we say that "I don't have to
> make this routine supper duper efficient cause I'd only save a half a
> nanosecond by removing those extra three operations." But then 20
> developers think this and  you have 20 pieces of software thinking
> they can waste time and then you get to the tortoise an d the hare.
> And I completely just went off topic, but it almost makes sense so I'm
> not gonna delete it.
>
> The point is, you need to ask yourself what your thread is doing. Is
> it sitting in a loop checking a file descriptor for input? If the
> answer to this or a similar question is yes, then you're doing
> something not right.
>
> Think of (worker) threads in two states, processing, or waiting for
> the kernel to tell them to start working.  Generally, if you're not
> doing something of use, you should be waiting in the kernel. (Typical
> examples of things to wait on: data to arrive on a file descriptor,
> data to finish being sent away, and of course mutexes, semaphores and
> condition variables)
>
> So basically it boils down to this, what is your thread doing? If its
> not doing hundreds or thousands of 3 dimensional fourier transforms,
> predicting stock market fluctuations using theories of chaotic
> dynamics, matrix reduction, or making sure planes don't crash, you're
> probably doing something wrong.  What this is exactly could be a
> number of things.
>
> If you want input, give a general outline of what you need to have
> happen. Glancing at your earlier emails, I only see that you're
> waiting on a background server somewhere to communicate with.  This
> could technically be done with a single thread and event driven
> programing. (Which is what glib and its main event loop are)
>
> Anyway, if that doesn't confuse you as much as it does me, let me know
> where you think you fall in the grand scheme of things and I'll try
> better to confuse you.
>
> Paul
>
> > Once again, thank you for your help.
> >
> > Sincerely
> > Melvin
> >
> >
> > On 1/25/07, Paul Davis <pjdavis engineering uiowa edu > wrote:
> > > Melvin,
> > >
> > > Is it *just* your app that becomes unresponsive? Or the entire
> > > desktop? Judging from the discussion I'm guessing that you wrote this
> > > with two threads. What I'm guessing is that your background thread has
> > > maxed out an entire processor. If you've only got one thread doing cpu
> > > intensive tasks it makes sense that it works fine on a dual cpu system
> > > and not a single cpu system.
> > >
> > > There are two methods I can see to solve this problem. The first and
> > > easiest to test and see if it works is to try and reduce the priority
> > > of your computation thread.
> > >
> > > The second is to rework your computational thread so that it
> > > periodically gives up control of the processor so that other process
> > > can run. Quite a bit more complex to accomplish in any meaningful way
> > > and its also quite dependant on the algorithm itself.
> > >
> > > > I have no idea how to fix this, I seemed to have made the fatal
> > assumption
> > > > that linux can time slice gthread code... Is this the problem?
> > > >
> > >
> > > I'm not entirely certain what you're asking. Of course linux is time
> > > slicing your program. This sounds like a typical resource starvation
> > > issue.
> > >
> > > HTH,
> > > Paul
> > >
> >
> >