apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PROPOSAL] Addition of apr_thread_yield() API...
Date Mon, 30 Jul 2001 20:44:30 GMT
From: "Justin Erenkrantz" <jerenkrantz@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?


View raw message