You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Brad Nicholes <BN...@novell.com> on 2001/07/30 20:54:18 UTC
[PROPOSAL] Addition of apr_thread_yield() API...
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();
}
thanks,
Brad
Re: [PROPOSAL] Addition of apr_thread_yield() API...
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Justin Erenkrantz" <je...@ebuilt.com>
Sent: Monday, July 30, 2001 3:15 PM
> 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
Actually, this could be very, very efficient from the perspective of WinNT fibers-as-threads
or any other pseudo-threading model.
That is, fibers are user-domain scheduled, and as such, this could work quite well.
I wish we had some WebTEN guys on this list to comment, since I recall MacOS(<X) was
not really preemptive either.
I agree they will inevitably cruft-up any app. Brad, what are the pain points that
you need addressed here? Are the Netware threads really that non-preemptive that it's
causing problems today in 1.3?
Bill
Re: [PROPOSAL] Addition of apr_thread_yield() API...
Posted by Aaron Bannert <aa...@ebuilt.com>.
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 :)
-aaron
Re: [PROPOSAL] Addition of apr_thread_yield() API...
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 30 July 2001 13:15, 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
This is actually the exact reason why it wasn't implemented to begin with,
so -0 from this side too.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: [PROPOSAL] Addition of apr_thread_yield() API...
Posted by Justin Erenkrantz <je...@ebuilt.com>.
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