Handling mq_open errors after mq_unlink

I am writing a client / server process on Suse Linux using Posix message queues to communicate, similar to the accepted answer in How to use mqueue in an ac program on Linux based system? ". When the server dies, it performs mq_close and mq_unlink . However, the client is not notified of this, so calls to mq_send on the client will continue to run even if the queue has been disconnected.

The problem is that when the server restarts, it tries to create a queue with mq_open with O_CREAT, but that fails because the client still has an open fd. Thus, although the filename in / dev / mqueue does not exist, the server cannot create it until the client exits and closes its file descriptor. I just wanted to make sure I got it right: If I wanted the server to close, disconnect and reopen mqueue (ex: with different attributes), is it really necessary for the client to either exit or close it with fd? This is very different from how it works with a simple file: I can delete a file that another process is using and the filesystem can rename it ".nfsXXX" and they can continue to use it, but I can make a new file with that name immediately.

My first attempt at fixing this is not to unbind the mqueue when logging out of the server - if I want to allow the server to restart without having to restart the client, then I suppose I shouldn't disable the queues (because the server knows the client is all can still use mqueue, it cannot be undone).

Ideally I would like the new mq_open to succeed on the server and the next mq_send to fail on the client. Is there an easy way to simulate this? The ways that happen to me are as follows:

• Executing fstat (or whatever) on "/ dev / mqueue / queueName" before every mq_send (yuck!) And closing fd if the name doesn't exist (while the server tries to recreate it in a loop), but even that doesn't work perfectly if the client is currently blocked on mq_send because the queue was full.
• has a separate socket in the client to which the server will send messages when it wants the client to close its queues (and possibly a separate thread in the client to monitor that socket).
• the server kills the client (s).