Re: sched_yield()

Поиск
Список
Период
Сортировка
От Mattias Kregert
Тема Re: sched_yield()
Дата
Msg-id 35146E54.A841F553@algonet.se
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6  (The Hermit Hacker <scrappy@hub.org>)
Ответы Re: sched_yield()  (The Hermit Hacker <scrappy@hub.org>)
Re: sched_yield()  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] Re: sched_yield()  (Tom <tom@sdf.com>)
Список 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 по дате отправления:

Предыдущее
От: ocie@paracel.com
Дата:
Сообщение: Re: [HACKERS] patch for memory overrun on Linux(i386)
Следующее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] patch for memory overrun on Linux(i386)