On 08/26/2010 09:22 PM, Tom Lane wrote:
> Not having to have a hard limit on the space for unconsumed messages?
Ah, I see. However, spilling to disk is unwanted for the current use
cases of imessages. Instead the sender needs to be able to deal with
out-of-(that-specific-part-of-shared)-memory conditions.
> Please note the coding rule that says that the code should not execute
> more than a few straight-line instructions while holding a spinlock.
> If you're copying long messages while holding the lock, I don't think
> spinlocks are acceptable.
Writing the payload data for imessages to shared memory doesn't need any
kind of lock. (Because the relevant chunk of shared memory got allocated
via wamalloc, which grants the allocator exclusive control over the
returned chunk). Only appending and removing (the pointer to the data)
to and from the queue requires taking a spinlock. And I think that still
qualifies.
However, your concern is valid for wamalloc, which is more critical in
that regard.
Regards
Markus
