search

OSVR / OSVR-Core

The core libraries, applications, and plugins of the OSVR software platform.
Apache License 2.0
329 stars 124 forks source link

osvrClientReleaseAutoStartedServer fails to close the OSVR server #557

Closed MarkVabulas closed 7 years ago

MarkVabulas commented 7 years ago

osvrClientReleaseAutoStartedServer() fails to actually stop an auto-started server. To reproduce, merely add a call to that function to the end of the auto-start C example before the end of main. The program will quit but the server will still be running. Tested on multiple independent workstations in Windows 10.

godbyk commented 7 years ago

osvrClientReleaseAutoStartedServer() shuts down the server on Android platforms, but leaves it running on all other platforms.

The intended use of JointClientKit is fairly narrow. May I ask why you're trying to start and stop the server from within your application? There may be a better solution or it may point to a shortcoming of the JointClientKit API.

JeroMiya commented 7 years ago

Perhaps the naming is misleading. The osvrClientReleaseAutoStartedServer method is intended to clean up any resources (objects, threads, etc...) allocated in the client by the corresponding call to start the server. On non-android platforms, auto-starting the server doesn't leave any resources in memory or start any threads in the client, so the osvrClientReleaseAutoStartedServer call has nothing to do. On Android, osvrClientReleaseAutoStartedServer stops the in-memory plugin host and server threads.

There are no immediate plans for client-side API to shut down or restart the OSVR server in the general case. The auto-start API is meant to be opaque and implementation specific to allow multiple OSVR deployment scenarios with the same client code. Server management, e.g. managing multiple distributed servers in wide-area tracking use-cases, or changing configuration and re-starting the server, is out of scope for osvrClientKit.

MarkVabulas commented 7 years ago

While developing the software, we haven't set up the OSVR server as a background service, and for various implementation-specific reasons we can't rely on it being pre-configured to do so. This necessitates starting the OSVR server from our application; the desired behavior of shutting it down is merely a desire to be a good neighbor and clean up resources when we're done with them. Furthermore, right now I don't see a way to start/host the OSVR server inside our application natively (that would of course be ideal).

JeroMiya commented 7 years ago

For OSVR Client applications, we don't recommend attempting to shut down the OSVR server, as this in and of itself can be disruptive to other applications. By design, the OSVR Client/Server architecture allows multiple clients for a single server, including clients on other machines accessing the server over the network (wide-area-tracking, etc...). In order to discourage one client application from disrupting another, we purposely do not have API to see what other clients are accessing a server, or to shut down the server. After all, shutting down the server while another client is accessing it will cause those other clients to stop functioning. From a UI standpoint, we provide a tray application separate from any OSVR Client application, that the user can use to start and shutdown the server or see if it's running.

Server process lifetime management is therefor outside the scope of the ClientKit, by design. If you have a scenario that requires you to manage the server startup and shutdown (and typically in these scenarios you know ahead of time exactly what client applications will be running), you'll need to implement it yourself per your specific needs. The auto-start API is not intended for this purpose.

MarkVabulas commented 7 years ago

Thank you for the information.