Re: Continuing the saga Non-Blocking GUI developement
- From: Paul Davis <paul linuxaudiosystems com>
- To: Melvin Newman <zexelon gmail com>
- Cc: gtk-list gnome org
- Subject: Re: Continuing the saga Non-Blocking GUI developement
- Date: Thu, 25 Jan 2007 11:14:06 -0500
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]