The wrapper server does some basic cleanup on unexpected exceptions, but it's not really robust yet. I can think of cases where cleanup isn't complete, with the result that callers may not ever get a response (which would probably cause them to hang). The library could use some hardening of the cleanup mechanism, proper notification of callers that a wrapper has crashed and burned, and more robust attempts to retrieve the wrapped object if necessary. A useful tool here is probably the Ractor monitoring mechanism (https://docs.ruby-lang.org/en/4.0/Ractor.html#method-i-monitor). There should be a way to monitor the server ractor (in isolated mode) or the server thread (in local mode) and deal with unexpected termination. This should include proper logging of the issue, but also a way to notify existing callers. The goal is for any unexpected termination of the server to cause all pending callers to raise an exception, making it impossible that a caller could hang.
The wrapper server does some basic cleanup on unexpected exceptions, but it's not really robust yet. I can think of cases where cleanup isn't complete, with the result that callers may not ever get a response (which would probably cause them to hang). The library could use some hardening of the cleanup mechanism, proper notification of callers that a wrapper has crashed and burned, and more robust attempts to retrieve the wrapped object if necessary. A useful tool here is probably the Ractor monitoring mechanism (https://docs.ruby-lang.org/en/4.0/Ractor.html#method-i-monitor). There should be a way to monitor the server ractor (in isolated mode) or the server thread (in local mode) and deal with unexpected termination. This should include proper logging of the issue, but also a way to notify existing callers. The goal is for any unexpected termination of the server to cause all pending callers to raise an exception, making it impossible that a caller could hang.