When the server side of a NamedPipe destructs it's endpoint, it can lead to a termination of the process using the client side.
It should behave more like a UnixDomainSocket where the server side can close a socket but the client side can still try to access it. In the worst case this will lead to a runtime error which can be handled gracefully.
Detailed information
On destruction, the server side NamedPipe destroys the NamedPipeData which will lead to the client side user of the NamedPipe accessing an invalid object. Instead of destruction the NamedPipeDataunconditionally, it could be marked for destruction. This could be done with an atomic (compare) exchange on a state variable, e.g.
enum class State {
READY,
IN_USE,
DESTRUCTION,
};
On construction the state variable will be set to READY.
When a client opens the NamedPipe, the state will be set to IN_USE by a compare and swap operation with READY being the expected state.
On destruction two scenarios need to be taken care of
The server side destroys the NamedPipe
a simple atomic exchange is sufficient
the server sets the state to DESTRUCTION
if the old value is READY, it can be destructed
if the old value is IN_USE, the client need to destroy the NamedPipe
The client side destroys the NamedPipe
since it is not the owner, it needs to do a compare and swap operation with READY as new state
the expected state is IN_USE
if the CAS failed and the actual state is DESTRUCTION, the client needs to destroy the NamedPipeData
Brief description
When the server side of a
NamedPipedestructs it's endpoint, it can lead to a termination of the process using the client side.It should behave more like a
UnixDomainSocketwhere the server side can close a socket but the client side can still try to access it. In the worst case this will lead to a runtime error which can be handled gracefully.Detailed information
On destruction, the server side
NamedPipedestroys theNamedPipeDatawhich will lead to the client side user of theNamedPipeaccessing an invalid object. Instead of destruction theNamedPipeDataunconditionally, it could be marked for destruction. This could be done with an atomic (compare) exchange on a state variable, e.g.On construction the state variable will be set to
READY.When a client opens the
NamedPipe, the state will be set toIN_USEby a compare and swap operation withREADYbeing the expected state.On destruction two scenarios need to be taken care of
NamedPipeDESTRUCTIONREADY, it can be destructedIN_USE, the client need to destroy theNamedPipeNamedPipeREADYas new stateIN_USEDESTRUCTION, the client needs to destroy theNamedPipeData