Skip site navigation (1) Skip section navigation (2)

Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Date: 2010-09-03 02:02:25
Message-ID: AANLkTin3OWJpUA6pzTEWyv2BvVSCz7R9U05ycJ1eYoR6@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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
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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-09-03 02:08:08
Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Previous:From: Alvaro HerreraDate: 2010-09-02 23:17:00
Subject: Re: returning multiple result sets from a stored procedure

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group