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: | 6BCB9D8A16AC4241919521715F4D8BCE17158E@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
anyway).
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?)
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2004-01-09 08:44:22 | Re: Win32 signal code - first try |
Previous Message | Bruce Momjian | 2004-01-09 04:58:27 | Re: [PATCHES] Proposed replacement for pipe under Win32 |