Re: Continuing the saga Non-Blocking GUI developement

["Melvin Newman" <zexelon gmail com>]

One point of interest, the loop i have does not continousely loop. The read() function that I use fore obtaining data from the joystick actualy blocks the entire thread until there is data ready. Therefore the thread does not operate unless the user is actually providing some input.

Also the thread actually samples data from the user (by sleeping for short terms) so as not to saturate the comunications lines. Even when the comunications / input thread is sitting idle the main gui thread does not appear to update the gui, and for all intents and purposes appears locked up. This only happens on my single proc laptop, everything runs perfectly on my multi-cpu system... this is the problem with having to code for the lowest common denominator.

Sincerely
Melvin Newman

On 1/25/07, Paul Davis <pjdavis engineering uiowa edu> wrote:

Melvin,

The conceptual is where its at. Once you have the concepts, the rest
is just syntax and implementation details.

As the other Paul mentioned, you should be using select() types of
calls on your file descriptors to do this type of action.

The concepts behind this are simple.  Your application is doing very
little actual work. Basically you're just telling the kernel "Send
data from this buffer to this file descriptor when data comes in."

The problem arises cause your program is in a loop that is asking "Do
I have data to send yet?" as fast as it possibly can.

So the idea here is this, have the kernel tell you when there's data
available, then your program comes to life and says "Now that I have
data, send it here" and then it goes back to waiting for more data.

When you get into network and file IO, the time you're spending is
largely waiting for the periperal devices to send and recieve data. So
instead of spending that time constantly asking if new data is
available, you just change things slightly to the idea of "When new
data is available, do this..."

Now, as to implementation...

I saw an earlier post that said not to use GIOChannel.  I'm not sure
why exactly they said that, but unless there's some portability issue
or implementation anomaly I'm not aware of, this is exactly what you
want.

Basically, youd create to GIOChannel objects to control the system.
One channel reads from the joystick and the other channel writes to
the server. Then your two functions just have to work nicely together
to keep the internal buffer in a valid state.

Once you get this working, your app is sending data to the server as
fast as the hardware allows. Now all you have to do is figure out if
the hardware is fast enough for your application, which I'm guessing
they are.

It might help to look at the design of other applications where
responsiveness and throughput are critical.  The first example that
comes to mind is an audio daemon or audo editing software. The other
Paul does some extremely impressive stuff with real time audio
editing.

HTH,
Paul

On 1/25/07, Paul Davis <paul linuxaudiosystems com> wrote:
> On Thu, 2007-01-25 at 11:06 -0500, Melvin Newman wrote:
> > Paul:
> >
> > Once again thank you for your reply. In responce to your longer e-mail
> > I have several points.
> >
> > 1) Your e-mail has been most helpfull conceptually, and yes I am going
> > to have take a closer look at exactly what my program is doing. With
> > regards to my program, while people "should not" die when it
> > malfunctions, it is controlling a remote vehicle work probably 1500
> > $... and it moves quite quickly, so if it where to hit a tree because
> > this program died, well things would not be pretty. So I would class
> > this program under mission critical.
> >
> > Basicaly what my backend thread does is precisely what you say it
> > should not do, it runs through a loop continousely reading from a file
> > descripter to a Joystick device. It then transmits these values to the
> > remote vehicle to command it to change direction or speed (via,
> > servos). Now I am not sure how to do things better such that I can
> > maintain as close to a 1:1 input to output timing without continousely
> > reading from this file descripter.
> >
> > 2) You are very correct in your reference to delays being relatively
> > insignificant in multi-ghz computers... unfortunately the laptop on
> > which this program must run is something like 700Mhz (actually it may
> > be 500Mhz, i cant remember and I cant check right now).
> >
> > In any event, thank you very much for your information, and if you
> > happen to have a better method for taking in user input from the
> > joystic, i would be glad to hear it.
>
> are you using poll/select to detect data from the joystick? many people
> will just write a tight non-blocking read(), which basically returns
> immediately saying "nothing to read". if you use select or poll (they
> are more or less 100% equivalent), your i/o thread will be asleep most
> of the time, except when there is data to read.
>
> --p
>
>
>