Re: sched_yield() - Mailing list pgsql-hackers

From Mattias Kregert
Subject Re: sched_yield()
Date
Msg-id 35146E54.A841F553@algonet.se
Whole thread Raw
In response to Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6  (The Hermit Hacker <scrappy@hub.org>)
Responses Re: sched_yield()
Re: sched_yield()
Re: [HACKERS] Re: sched_yield()
List pgsql-hackers
The Hermit Hacker wrote:
>
> What's the possibility of doing this similar to how we do some of
> the other functions (dl_open comes immediately to mind)...make a
> pg_sched_yield function and use that, which is built based on the various
> platforms?
>
>         Right now, I don't believe we have *anything* in place, so have
> pg_sched_yield() return 0 (or an equivalent) for every platform except for
> Linux...

But sched_yield() is not Linux-specific:
-- The sched_yield() function relinquishes the processor for the
-- running process.
-- IEEE Std 1003.1b-1993, §13.3.5. (POSIX real-time standard 1003.lb)

Except from Linux, I can find references to sched_yield() in LynxOS,
DECthreads thread library, AIX 4.1 and up (libc), Solaris (thread.h
(c)1994 Sun
Microsystems), Unix98, GNU, C EXECUTIVE(r) and PSX(tm) real time kernels
...
This is just a quick search.

Perhaps we should enable sched_yield() for every OS except for... well,
what's the
name of that OS which does not have sched_yield()...  FreeBSD ;)

After all, sched_yield() is five years old. Any reasonable OS should
have it.

/* m */

pgsql-hackers by date:

Previous
From: ocie@paracel.com
Date:
Subject: Re: [HACKERS] patch for memory overrun on Linux(i386)
Next
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] patch for memory overrun on Linux(i386)