From: | Kevin Brown <kevin(at)sysexperts(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Unixware 714 pthreads |
Date: | 2004-10-28 22:28:43 |
Message-ID: | 20041028222843.GB17583@filer |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> ohp(at)pyrenet(dot)fr writes:
> > On Thu, 28 Oct 2004, Tom Lane wrote:
> >> No. Why should the signal handler need re-arming?
>
> > My impression was that once caught, signal handler for a particular signal
> > is reset to SIG-DFL.
>
> No. If your signal support is POSIX-compatible, it should not do that
> because we don't set SA_RESETHAND when calling sigaction(2). If you
> don't have POSIX signals, you had better have BSD-style signal(2),
> which doesn't reset either. If this is not happening as expected,
> you will have much worse problems than whether statement_timeout works :-(
SysV-style signal(2) handling does indeed require that the signal
handler be re-enabled. The attached program demonstrates this on
Solaris, and probably on Unixware as well (I don't have access to the
latter). Just run it and interrupt it with ctrl-c. It should print
something the first time around, and actually be interrupted the
second time.
So if Unixware doesn't have sigaction() or it's not being picked up by
autoconf then yeah, he'll have big problems...
--
Kevin Brown kevin(at)sysexperts(dot)com
Attachment | Content-Type | Size |
---|---|---|
sigtest.c | text/x-csrc | 268 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-10-28 22:32:49 | Re: -HEAD contrib/dblink regress failure on SPARC/Solaris 8 |
Previous Message | Josh Berkus | 2004-10-28 21:35:16 | Suggestion: additional system views |