Skip site navigation (1) Skip section navigation (2)

Thread-safe signals

From: "Steve Tibbett" <stibbett(at)zim(dot)biz>
To: "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Thread-safe signals
Date: 2003-12-16 22:39:26
Message-ID: 546CD3100F4C0F42A30A94C0F2B349148FC67C@zimmail1.zim.zimismobile.com (view raw or flat)
Thread:
Lists: pgsql-hackers-win32
Someone mentioned a while ago that the signal handlers might not need to
be run on the main thread, making much of this issue moot.  I did some
checking on this and it looks like that might be the case.

We know we have the ability to receive signals on a separate thread and
respond to them instantly.. I believe this is sufficient for postmaster.

In the agent, some of the handlers don't do much:

quickdie
	writes error message, calls exit(1)

pgstat_die
	exit(1)

authdie
	exit(0)
	
SigHupHandler
	got_SIGHUP = true;
	
These are the handlers I found that look like they could be significant:

die
	This is postgres receiving an abort request from postmaster.  
	Aborts transaction and quits as soon as possible.  
	Does this via:
		InterruptPending = true;
		ProcDiePending = true;
		...
		LockWaitCancel();
		...

StatementCancelHandler
	Query-cancel signal from postmaster: abort current transaction
	at soonest convenient time.  Sets the QueryCancelPending and 
	InterruptPending flags, calls LockWaitCancel if it seems safe
	(ImmediateInterruptOK, CritSectionCount==0,
InterruptHoldoffCount==0)

handle_sig_alarm
	Calls CheckDeadLock and CheckStatementTimeout
	
Async_NotifyHandler
	Calls ProcessIncomingNotify if it thinks it's safe to do so, 
	otherwise lets it happen later.  What would be the implication
of
	letting it happen later?

handle_sigint
	sets cancel_pressed, calls PQrequestCancel which looks like 
	it would be safe from a separate thread

If LockWaitCancel, CheckDeadLock, CheckStatementTimeout, and
ProcessIncomingNotify would be thread-safe (or could be deferred until
the main thread was done with the statement it's working on), then
the whole signal problem goes away.  Anyone familiar enough with these
to say?

--
Steve Tibbett
stibbett(at)zim(dot)biz



pgsql-hackers-win32 by date

Next:From: Hannu KrosingDate: 2003-12-16 23:08:25
Subject: Re: [pgsql-hackers-win32] [PATCHES] fork/exec patch
Previous:From: Neil ConwayDate: 2003-12-16 22:37:31
Subject: Re: [pgsql-hackers-win32] [PATCHES] fork/exec patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group