apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: [PROPOSAL] Addition of apr_thread_yield() API...
Date Mon, 30 Jul 2001 20:45:46 GMT
On Mon, Jul 30, 2001 at 01:15:32PM -0700, Justin Erenkrantz wrote:
> On Mon, Jul 30, 2001 at 12:54:18PM -0600, Brad Nicholes wrote:
> >     I would like to propose adding the function apr_thread_yield() as part of the
threading API's.  The reason for this to to allow applications to force a thread to yield
the processor during a compute bound operation.  On the NetWare platform, not yielding the
processor in a timely fashion can cause the entire server to become sluggish.  The implementation
of this routine for NetWare would be as simple as:
> > 
> > void apr_thread_yield()
> > {
> >     NXThreadYield();
> > }
> I'm not sure that this is a good idea (esp. considering that sched_yield
> on POSIX systems is not well-defined - it depends on your scheduling
> policy).
> On most OSes, this should be a no-op (as the OS should be handling 
> this via preemption).  I'm not a fan of adding apr_thread_yield() 
> throughout to support a poor OS scheduler.
> So, -0 from me (I won't stop you, but I don't like it).  -- justin

That was also my initial reaction, but now I'm thinking that in a build
or platform where only userspace thread implementation exists, this is
an [unfortunate] necessity.

We will of course have to litter these types of calls throughout processor
intensive pieces of code, like Brad mentioned.

So I'm +1 (but I'm not an APR committer, so take it FWIW :)

View raw message