On Wed, May 22, 2002 at 01:59:02PM -0400, Cliff Woolley wrote: > On Wed, 22 May 2002, Aaron Bannert wrote: > > > The reason it's not implemented is because it's not guaranteed to do > > anything. Yielding is up to the discresion of the underlying system, > > and depending on many things it may behave differently. We can not > > get predictable scheduling with any variant of yield() in a way that > > will be portable. The only method we have right now for predictable > > scheduling in APR is apr_thread_cond.h. > > I'd say it's up to us to guarantee that it *does* do something on a > cross-platform basis. That's APR's job. If we're not going to do that, > then it needs to go away. Having a function in the API that doesn't do > what it's supposed to do uniformly across platforms is bad karma. It > works on Win32, why shouldn't it work on Unix?
IIRC, this function exists so that netware and other single-multiplexed-process based thread libraries can have finer-grain control over execution sharing. The use case is a large computationally expensive function that hogs the CPU for a long time and can't yield the CPU since it hits none of the yieldable system calls. On systems that do true context switching between userspace threads, this doesn't need to be implemented. It in no way guarantees that the execution will be yielded, since that's up to the scheduling mechanism. -aaron
