Im writing some fairly generic visualisation stuff that works with
player and ive come accross some thread issues...
Basically my rendering thread is run seperately from the data update
I want to have one data update thread for several player devices which
all connect through one playerclient object...
There are two basic issues...
1) the read call is blocking and does the data updates, so in order to
be thread safe I have to hold a mutex lock on a blocking call (not good
2) Additional proxies may be added to the playerclient object after the
update thread is started (ie blocking on the read)
if i am in pull new mode and no new data is coming in then the blocking
read blocks for ever...this also blocks the server thread for the client
connection and thus the request device access calls also block (so no
new devices can connect to break the read lock)
The first issue can probably solved by simply creating two calls, "Read"
and "PushDataToProxies" (probably not good names) that way you can
simply lock in the second call...
The second issue is a little more complex I guess...would it be easy to
allow the server to react to new commands while it is waiting on data
from the drivers? I guess its only fatal when you do a pull new read on
a playerclient with no active proxies.....so could simply fail a
playerclient read when no proxies are active for the client...
Finally, should any 'thread safing' be done as a few function changes
that allow client software to force thread safety (ie by manually
calling 'read new data' 'then client side lock' then 'push updates to
proxies' then 'unlock', or as a compile flag in the client so thread
safety is transparent (--enable-threadsafe-clientlibs)
Let me know if im plain old going about this the wrong way, or which of
the above options will work/wont work....