Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) - Mailing list pgsql-hackers

From Tom Samplonius
Subject Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Date
Msg-id Pine.BSF.4.05.10011162059510.11338-100000@misery.sdf.com
Whole thread Raw
In response to Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Alfred Perlstein <bright@wintelcom.net>)
Responses Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Bruce Momjian <pgman@candle.pha.pa.us>)
WAL fsync scheduling  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Thu, 16 Nov 2000, Alfred Perlstein wrote:

> * Larry Rosenman <ler@lerctr.org> [001116 12:09] wrote:
> > * Bruce Momjian <pgman@candle.pha.pa.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? 
> 
> sleep(3) should conform to POSIX specification, if anyone has the
> reference they can check it to see what the effect of sleep(0)
> should be.
 Yes, but Posix also specifies sched_yield() which rather explicitly
allows a process to yield its timeslice.  No idea how well that is
supported.

> -- 
> -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
> "I have the heart of a child; I keep it in a jar on my desk."

Tom



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [rfc] new CREATE FUNCTION (and more)
Next
From: Grant Finnemore
Date:
Subject: Failure to recognise new database