But do we really need the slots mechanism? Would it not be OK to just let the LWLock do the sequencing of concurrent requests? Given that we only going to use one message queue per cluster, there's not much concurrency you can gain by introducing slots I believe.
I afraid of problems on production. When you have a queue related to any process, then all problems should be off after end of processes. One message queue per cluster needs restart cluster when some pathological problems are - and you cannot restart cluster in production week, sometimes weeks. The slots are more robust.
Yes, but in your implementation the slots themselves don't have a queue/buffer. Did you intend to have a message queue per slot?
The message queue cannot be reused, so I expect one slot per caller to be used passing parameters, - message queue will be created/released by demand by caller.
I don't believe a message queue cannot really be reused. What would stop us from calling shm_mq_create() on the queue struct again?
you cannot to change recipient later
Well, maybe I'm missing something, but sh_mq_create() will just overwrite the contents of the struct, so it doesn't care about sender/receiver: only sh_mq_set_sender/receiver() do.
if you create sh_mq from scratch, then you can reuse structure.
