On Tue, Jun 24, 2014 at 12:08 PM, John Lumby <johnlu...@hotmail.com> wrote: >> The question is, if you receive the notification of the I/O completion >> using a signal or a thread, is it safe to release the lwlock from the >> signal handler or a separate thread? > > In the forthcoming new version of the patch that uses sigevent, > the originator locks a LWlock associated with that BAaiocb eXclusive, > and , when signalled, in the signal handler it places that LWlock > on a process-local queue of LWlocks awaiting release. > (No, It cannot be safely released inside the signal handler or in a > separate thread). Whenever the mainline passes a CHECK_INTERRUPTS macro > and at a few additional points in bufmgr, the backend walks this > process-local > queue and releases those LWlocks. This is also done if the originator > itself issues a ReadBuffer, which is the most frequent case in which it > is released.
I suggest using a semaphore instead. Semaphores are supposed to be incremented/decremented from multiple threads or processes already. So, in theory, the callback itself should be able to do it. The problem with the process-local queue is that it may take time to be processed (the time it takes to get to a CHECK_INTERRUPTS macro, which as it happened with regexes, it can be quite high). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
