Open rpavlik opened 9 years ago
I wonder if we're seeing a race between the connection start up and the ping request coming from the client. One odd thing to try is to put a vrpn_SleepMsecs(1) inside the spin-wait loop. I've seen that work better on some systems. It must be yielding to the kernel more often or something.
Here's the code doing the client startup - I thought I had committed a sleep in there, but apparently I just tested one locally and sent a DLL somewhere to test (which reportedly showed the same issue) https://github.com/OSVR/OSVR-Core/blob/master/src/osvr/Client/PureClientContext.cpp#L91
May be fixed by #240 (specifically, the queuing and deduplication of the hardware detection and path tree sending).
cc @russell-taylor since this might be VRPN-related.
The creation of a client context includes a startup "spin" where we wait, up to a fixed timeout (500ms or 1s at the moment, IIRC), to get an established VRPN connection and receive a path tree from the server. On some systems, we'll get a VRPN connection within that time, but won't get a path tree reliably within the timeout. (When we do get one, it comes quickly: on the order of 60ms)
Not sure the server setup for reproduction, besides that it does happen with an experimental server analysis plugin using the OSVR public APIs, and that it also happens with servers as shipping. For games, it's not typically an issue, since they will start calling update in their mainloop and when they get the tree eventually it will set up all interface objects and handlers correctly, but for apps like
osvr_print_tree
that basically just fire up the client for the express purpose of getting the path tree, it's problematic.osvr_print_tree
is the easiest client to reproduce this with.