Gregory Stark wrote:
> "Andrew Dunstan" <andrew@dunslane.net> writes:
>
>
>>>> and b) that there is broad agreement on the general design (i.e. to use a
>>>> circular buffer in shared memory, of configurable size, to hold the
>>>> outstanding message queue).
>>>>
>>> Would it spill out to disk and expand (and shrink again) as required? Loss of
>>> notifications should not occur imho.
>>>
>> No loss, but, per previous discussion, it would block and try to get other
>> backends to collect their outstanding notifications.
>>
>> Let's say we provide 100Kb for this (which is not a heck of a lot) , that the
>> average notification might be, say, 40 bytes of name plus 60 bytes of message.
>> Then we have room for about 1000 messages in the queue. This would get ugly
>> only if backend presumably in the middle of some very long transaction, refused
>> to pick up its messages despite prodding. But ISTM that means we just need to
>> pick a few strategic spots that will call CHECK_FOR_NOTIFICATIONS() even in the
>> middle of a transaction and store them locally.
>>
>
> Keep in mind that the usual place you run into problems with this type of
> buffering is where you have two processes talking to each other. Say a
> producer-consumer type of design. You want to be sure you never deadlock
> with each process waiting for the other to consume a notification.
>
> I don't think this is a problem in this case because it just means the state
> you enter when you're blocked waiting for your buffer to have free space MUST
> be amongst the times you call CHECK_FOR_NOTIFICATIONS(). If you didn't plan to
> have this local storage in the backend it would be difficult to guarantee that
> clients would handle this situation correctly.
>
> Perhaps that was obvious already. If so, sorry for worrying for nothing.
>
>
>
No, it's a good point.
the pseudo-code might look something like
loop res = enqueue_notification collect_my_messages exit when res == success send_out_signal sleep_a_bit
end loop
That should be enough I think.
cheers
andrew
