Re: [HACKERS] unexpected SIGALRM

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, pgsql-cygwin(at)postgresql(dot)org
Subject: Re: [HACKERS] unexpected SIGALRM
Date: 2001-12-17 01:47:24
Message-ID: 27674.1008553644@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-cygwin pgsql-hackers

Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> Tom Lane wrote:
>> I'm not excited about inserting an ad-hoc test to work
>> around (only) one manifestation of a system-level bug.

> OK so cygwin isn't considered as a supported platform ?

I don't consider it our responsibility to work around cygwin bugs,
as opposed to reporting said bugs and expecting the cygwin folk to
fix 'em.

If the cost of such a workaround is minimal, then I'd be willing to
consider it; but in this case, you're talking about adding another pair
of kernel calls to every lock blockage. That seems nontrivial.
But the more important argument is this: if cygwin contains a bug that
allows it to fire interrupts when it should not, how much improvement
do we really get from plugging this one hole? Surely there are other
places that will have similar problems. For that matter, how can you
be sure that adding a sigsetmask call will prevent it from firing the
interrupt --- how is that any more secure than setitimer?

I'd say the correct course of action is to report the problem to the
cygwin people first, and ask them whether a user-level workaround is
possible/useful.

regards, tom lane

In response to

Responses

Browse pgsql-cygwin by date

  From Date Subject
Next Message Hiroshi Inoue 2001-12-17 03:19:20 Re: [HACKERS] unexpected SIGALRM
Previous Message Hiroshi Inoue 2001-12-17 01:34:02 Re: [HACKERS] unexpected SIGALRM

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Sabino Mullane 2001-12-17 01:56:38 Re: pgsql's datetime perl equivalent ?
Previous Message Hiroshi Inoue 2001-12-17 01:34:02 Re: [HACKERS] unexpected SIGALRM