Re: Continuing the saga Non-Blocking GUI developement



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]