From: Jordi <mu...@gm...> - 2006-03-17 09:51:28
|
What about this: driver() { DonLetNewMessagesIn ProcessMessages LetNewMessagesIn Here goes other important driver code } Before entering ProcessMessages we avoid new messages in. If the client sen= d=20 us a message while in this state, the call will wait (so the client will ru= n=20 slower, waiting till the driver is ready) till LetNewMessagesIn is called. I don't know how the messages are sent from client to server, so I don't kn= ow=20 if this will be a good solution. =46riday, 17 de March de 2006 06:12=E3=80=81Geoffrey Biggs =E3=81=95=E3=82= =93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=97=E3=81=9F: > The server has had it's turn, now it's the turn of the clients. We've > found a problem with the way messages from clients to drivers are handled. > > The problem is this: When a driver calls ::ProcessMessages, this > function will keep processing messages until the queue for that driver > is empty. Standard practice is to call this function from your driver's > main loop. When it returns, you do other driver stuff. For example, the > p2os driver will call this function, handle any messages, and once it > returns handle stuff like the blobfinder and any subscribe/unsubscribe > changes that change the status of powered things like sonar and the arm. > But if clients send messages too fast, ProcessMessages won't be able to > handle them fast enough and will never get to a state where it finds the > queue is empty. As a result, anything that needs to be done in the main > loop will never get done. In the case of p2os, this is turning on and > off hardware, for example. Even if you use replace rules, you'll still > have at least one command waiting in the queue at all times. > > We found this because we found that both playerv with position command > mode on and playerjoy -c will send commands so fast that we couldn't > subscribe to the arm and have it turn on. > > How to solve this is a difficult problem. Anyone got any ideas? > > Geoff > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live > webcast and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers |