From the terminal, a running VDMS server, when a SIGINT (via crtl-c) is sent, the server continues to run rather than gracefully terminating and returning to the command line. To terminate the server I have to do a kill -9 command.
Context:
The short version is that the connection class logic uses a blocking socket which will hold onto a thread indefinitely if not connections are incoming.
While the autodelete/replicate threads were definitely a part of the problem and were easy enough to fix, we still can have the VDMS server hang when control C is pressed if new connections are not incoming. If new connections are incoming everything shutdowns as expected.
This is because the server side logic has a separate thread that does a blocking creation of a new connection object, waiting for new incoming connections to be initiated. And this thread will hold up the entire shutdown sequence if its not running. Unfortunately, this has several layers of somewhat sensitive additional logic under it to be teased apart.
One possible solution is to change the connection server logic to use a non-blocking accept logic, however this adds a moderate amount complexity in that we must now check for an EAGAIN status on failure, and force a retry (which itself requires either sleeping which may impact performance, or busy-waiting which eats up a CPU core) . Its also not clear to me yet how many locations rely on the blocking connection logic with VDMS.
Another possible solution I'm looking at is setting a signal timer to force a thread interruption on that blocking call to then check for the server shutdown state, but this is messy and introduces its own challenges cause signal handling is its own beast.
From the terminal, a running VDMS server, when a SIGINT (via crtl-c) is sent, the server continues to run rather than gracefully terminating and returning to the command line. To terminate the server I have to do a kill -9 command.
Context:
The short version is that the connection class logic uses a blocking socket which will hold onto a thread indefinitely if not connections are incoming.
While the autodelete/replicate threads were definitely a part of the problem and were easy enough to fix, we still can have the VDMS server hang when control C is pressed if new connections are not incoming. If new connections are incoming everything shutdowns as expected.
This is because the server side logic has a separate thread that does a blocking creation of a new connection object, waiting for new incoming connections to be initiated. And this thread will hold up the entire shutdown sequence if its not running. Unfortunately, this has several layers of somewhat sensitive additional logic under it to be teased apart.
One possible solution is to change the connection server logic to use a non-blocking accept logic, however this adds a moderate amount complexity in that we must now check for an EAGAIN status on failure, and force a retry (which itself requires either sleeping which may impact performance, or busy-waiting which eats up a CPU core) . Its also not clear to me yet how many locations rely on the blocking connection logic with VDMS.
Another possible solution I'm looking at is setting a signal timer to force a thread interruption on that blocking call to then check for the server shutdown state, but this is messy and introduces its own challenges cause signal handling is its own beast.