'NamedPipe' should be more robust

[elBoberido]

Brief description

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

1. 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
2. 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