2008/10/1 Paul Osmialowski <email@example.com>
Recently I was experiencing serious problems with server->server
communication. I was suspecting the problem must have been caused by
recent changes in player core. So I started to dig for the reason.
Finally, I must tell that I had to dig really deeply as I've found the
reason inside of libplayertcp(). All the problems were caused by someone
who removed virtual Update() method from TCPRemoteDriver class. Its
implementation was calling Lock() and Unlock() methods from PlayerTCP
class. These methods were moved to private section so I coulnd't use them
from Update() method that I've reverted in TCPRemoteDriver. So I made them
public back again. After these changes, all my problems has gone.
Removing Update() method from TCPRemoteDriver caused it impossible to call
Request() with threaded parameter set to false. It is rather rare case, as
most of the Request calls are done while driver thread is running.
Unfortunately, linuxjoystick driver calls Request() method from its
Setup() method rihgt before driver thread is created - so the threaded
parameter is false (and I guess it should be).
I don't really know why Update() method was removed from TCPRemoteDriver
and if it is an error or it should be like that which means, Request
method should be rewritten so it handles not threaded case different way.
Someone more responsible than my humble person should justify that.
Also I've realised that setting rate parameter to 0 while running playerv
solves all my problem with bad communication link between desktop and
Roomba robot. I don't remember well, but something tells me that once it
was like that by default and recent change of default value of this
parameter to 5 has caused all my client->server problems.
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Playerstage-developers mailing list