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@xxxxxxxxxxxxxxxxxxxxx> 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 > > > _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
