Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 30 Jul 2001 13:15:32 -0700
From: Justin Erenkrantz <jerenkrantz@ebuilt.com>
To: Brad Nicholes <BNICHOLES@novell.com>
Cc: dev@apr.apache.org
Subject: Re: [PROPOSAL] Addition of apr_thread_yield() API...
Message-ID: <20010730131532.D25818@ebuilt.com>
References: <sb655900.070@prv-mail20.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <sb655900.070@prv-mail20.provo.novell.com>;
 from BNICHOLES@novell.com on Mon, Jul 30, 2001 at 12:54:18PM -0600

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