On Fri, Sep 3, 2010 at 5:13 AM, Tom Lane <t...@sss.pgh.pa.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
ending.
> 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.)
Agreed.
> 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.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
