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

Re: Win32 signal code - first try

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Claudio Natoli" <claudio(dot)natoli(at)memetrics(dot)com>,"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 08:42:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
> > 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.

No, absolutely not. It's supposed to be bogus :-) SleepEx() will give up
the remainder of the threads quantum to another thread. This means the
call often takes as much as 10ms to complete, which is *not* good if we
poll it in a loop somewhere performance critical.

> 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).
Hmm. Yeah, that might be necessary.

> 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).

Hmm. Of all signals, only SIGFPE and SIGABRT may be generated (since
we're no NT - in 9x SIGINT can be called, but we don't support that
Will SIGABRT ever be called, really? Or can we ignore that one too?

As for pg_queue_signal:ing them - this one makes a system call
(QueueUserAPC). We are explicitly told *not* to make system calls inside
signal handlers in the docs. We probably need to handle this one with
just setting a variable to 1.

> [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.

Ehh. That is a good question. Can't find any documentation at all about
it. Since it's not listed as a restriction (which they are on other
places), I'd assume it's safe.

(The docs clearly state we cannot use longjmp from any other signal
handlers than FPE in the CRT, though - but we don't use those. Are you
sure that is allowed on other platforms?)


pgsql-hackers-win32 by date

Next:From: Magnus HaganderDate: 2004-01-09 08:44:22
Subject: Re: Win32 signal code - first try
Previous:From: Bruce MomjianDate: 2004-01-09 04:58:27
Subject: Re: [PATCHES] Proposed replacement for pipe under Win32

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