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

Re: Win32 signal code - first try

From: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
To: 'Magnus Hagander ' <mha(at)sollentuna(dot)net>,'Merlin Moncure ' <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: 'pgsql-hackers-win32 ' <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: Win32 signal code - first try
Date: 2004-01-09 00:41:22
Message-ID: A02DEC4D1073D611BAE8525405FCCE2B0280CC@harris.memetrics.local (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
> I think we agreed that we'd go with the polling method if it worked well
> enough, so we don't need a kernel driver. If that doesn't work out, the
> kernel driver would be the fallback method. 

I still hoping we won't need the kernel driver method...

> Looking at this code, I'm thinking we can probably do away with the
critical section alltogether. All that code now executes on the main
thread. Does this seem correct?

I've only given the code a superficial look, but I agree.

A few comments.

Firstly, I think the WaitForMultipleObjectsEx call in 
__pg_poll_signals is bogus. You're probably after SleepEx(0,TRUE), or
something of the like.

Secondly, in your pg_signal_apc, you ignore SIG_DFL handling. I actually
think we'll need to keep a list of the default function calls for each type
of signal, and call those functions (instead of ignoring the call).

The rationale for this thinking is that, whilst the current code seems to be
able to handle interprocess signals within the postmaster/postgres system
nicely, all signals that are raised as a result of process execution (eg.
SIGABRT, SIGFPE, ...) and those that come externally (eg. SIGINT from a
Ctrl-C at the command line) will need to be caught in a dummy handler which
makes a call to pg_queue_signal (note that we can't just use pg_queue_signal
as the dummy handler, as I think this dummy handler will also need to reset
itself as the signal handler for all signals other than SIGFPE).

[In other words, when a SIGFPE occurs, then we'll catch it, and queue an APC
for it. If, for instance, FloatExceptionHandler is set as the handler, it'll
get called, or if SIGDFL is set, then we'll terminate.]

Lastly, how will this code play with the setjmp/longjmp calls? Specifically,
can we make a longjmp out of a APC, as will occur when, for instance, a
query is cancelled? This is the only thing that's troubling me.

Again, this looks good. I'm really looking forward to dropping it into my
code base and trying it out over the weekend.

Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 

pgsql-hackers-win32 by date

Next:From: Bruce MomjianDate: 2004-01-09 00:41:32
Subject: Re: fork/exec patch: pre-CreateProcess finalization
Previous:From: Tom LaneDate: 2004-01-09 00:24:04
Subject: Re: fork/exec patch: pre-CreateProcess finalization

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