On 2 November 2016 at 02:10, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Nov 1, 2016 at 12:35 PM, Abbas Butt <abbas.butt@enterprisedb.com> wrote:
>> Hi,
>> Consider this situation:
>> 1. I have a background worker process.
>> 2. The process creates a latch, initializes it using InitLatch & resets it.
>> 3. It then creates a thread and passes the latch created in step 2 to it.
>> To pass it, the process uses the last argument of pthread_create.
>> 4. The thread blocks by calling WaitLatch.
>> 5. The process after some time sets the latch using SetLatch.
>>
>> The thread does not notice that the latch has been set and keeps waiting.
>>
>> My question is:
>> Are latches supposed to work between a process and a thread created by that
>> process?
>
> Nothing in the entire backend is guaranteed to work if you spawn
> multiple threads within the same process.
>
> Including this.
Yep.
You could have the main thread wait on the latch, then signal the
other threads via appropriate pthread primitives. But you must ensure
your other threads do nothing that calls into backend code. Including
things like atexit handlers. They need to coordinate with the main
thread to do everything PostgreSQL related, and you'd need to make
sure the main thread handles all signals. That's the default for Linux
- the main thread gets first chance at all signals and other threads'
sigmasks are only checked if the main thread has masked the signal,
but that means your other threads should be sure to mask all signals
used by PostgreSQL. Good luck doing that portably.
There are exceptions where you can call some backend functions and
macros from other threads. But you'd have to analyse each on a case by
case basis, and there's no guarantee they'll _stay_ safe.
I'd just avoid using threads in the backend if at all possible.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services