Re: shared memory message queues

2013/12/6 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
> What will happen if sender tries to send a large chunk that needs to
> be split into multiple sub-chunks and receiver concurrently detaches
> itself from the queue during the writes by sender?
> It seems to me the sender gets SHM_MQ_DETACHED and only
> earlier half of the chunk still remains on the queue even though
> its total length was already in the message queue.
> It may eventually lead infinite loop on the receiver side when another
> receiver appeared again later, then read incomplete chunk.
> Does it a feasible scenario? If so, it might be a solution to prohibit
> enqueuing something without receiver, and reset queue when a new
> receiver is attached.
>
Doesn't it an intended usage to attach a peer process on a message
queue that had once detached, does it?
If so, it may be a solution to put ereport() on shm_mq_set_receiver()
and shm_mq_set_sender() to prohibit to assign a process on the
message queue with mq_detached = true. It will make the situation
simplified.

Regarding to the test-shm-mq-v1.patch, setup_background_workers()
tries to launch nworkers of background worker processes, however,
may fail during the launching if max_worker_processes is not enough.
Is it a situation to attach the BGWORKER_EPHEMERAL flag when
your patch gets committed, isn't it?
I think it is waste of efforts to add error handling here instead of the
core support to be added, however, it makes sense to put a source
code comment not to forget to add this flag when it came.

Also, test_shm_mq_setup() waits for completion of starting up of
background worker processes. I'm uncertain whether it is really
needed, because this shared memory message queue allows to
send byte stream without receiver, and also blocks until byte
stream will come from the peer to be set later.
This module is designed for test purpose, so I think it makes more
sense if test condition is more corner case.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>