On Fri, Sep 3, 2010 at 5:13 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Does ReleaseLatch() have any actual use-case, and if so what would it be?
> I think we could do without it.
In Unix, probably we can live without that. But in Windows, we need to
free SharedEventHandles slot for upcoming process using a latch when
> The WaitLatch timeout API could use a bit of refinement. I'd suggest
> defining negative timeout as meaning wait forever, so that timeout = 0
> can be used for "check but don't wait". Also, it seems like the
> function shouldn't just return void but should return a bool to show
> whether it saw the latch set or timed out. (Yeah, I realize the caller
> could look into the latch to find that out, but callers really ought to
> treat latches as opaque structs.)
> I don't think you have the select-failed logic right in
> WaitLatchOrSocket; on EINTR it will suppose that FD_ISSET is a valid
> test to make, which I think ain't the case. Just "continue" around
> the loop.
EINTR already makes us go back to the top of the loop since FD_ISSET(pipe)
is not checked. Then we would clear the pipe and break out of the loop
because of "latch->is_set == true".
> + * XXX: Is it safe to elog(ERROR) in a signal handler?
> No, it isn't.
We should use elog(FATAL) or check proc_exit_inprogress, instead?
+ if (errno != EAGAIN && errno != EWOULDBLOCK)
+ * XXX: Is it safe to elog(ERROR) in a signal handler?
+ elog(ERROR, "write() on self-pipe failed: %m");
+ if (errno == EINTR)
+ goto retry;
"errno == EINTR)" seems to be never checked.
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2010-09-03 02:08:08|
|Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!) |
|Previous:||From: Alvaro Herrera||Date: 2010-09-02 23:17:00|
|Subject: Re: returning multiple result sets from a stored procedure|