From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Larry Rosenman <ler(at)lerctr(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) |
Date: | 2000-11-16 20:27:29 |
Message-ID: | 200011162027.PAA28316@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> * Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> [001116 14:02]:
> > > > This sounds like an interesting approach, yes.
> > > Question: Is sleep(0) guaranteed to at least give up control?
> > >
> > > The way I read my UnixWare 7's man page, it might not, since alarm(0)
> > > just cancels the alarm...
> >
> > Well, it certainly is a kernel call, and most OS's re-evaluate on kernel
> > call return.
> BUT, do we know for sure that sleep(0) is not optimized in the library
> to just return?
We can only do our best here. I think guessing whether other backends
are _about_ to commit is pretty shaky, and sleeping every time is a
waste. This seems the cleanest.
Funny you should mention the optimization. I just checked BSDI and saw:
u_int
sleep(secs)
u_int secs;
{
struct timeval nt, ot;
long diff;
int rc;
if (secs == 0)
return (0);
So maybe we need another _fake_ kernel call, or a select/usleep with a
very small value.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-11-16 20:57:57 | Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) |
Previous Message | Alfred Perlstein | 2000-11-16 20:12:58 | Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) |