Re: sched_yield()
От | The Hermit Hacker |
---|---|
Тема | Re: sched_yield() |
Дата | |
Msg-id | Pine.BSF.3.96.980321212742.324G-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Re: sched_yield() (Mattias Kregert <matti@algonet.se>) |
Ответы |
Re: [HACKERS] Re: sched_yield()
Re: sched_yield() |
Список | pgsql-hackers |
On Sun, 22 Mar 1998, Mattias Kregert wrote: > 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. You missed my point...so far as I've heard, there are two ways of doing what is being proposed...either using sched_yield() on those systems that support it, or select() on those that don't. If you are going to build a patch for this, it should look something like: #ifdef HAVE_SCHED_YIELD <insert sched_yield() code here> #else <insert select() code here> #endif Totally 'configure' configurable, and non-system dependent :) Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
В списке pgsql-hackers по дате отправления: