apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: [PROPOSAL] Addition of apr_thread_yield() API...
Date Mon, 30 Jul 2001 21:57:37 GMT
    I can't really point to a problem area in Apache 2.0 yet since we are still in the early
stages of our port to NetWare.  But you can do a quick search in the 1.3 tree for calls to
ThreadSwitch() and ThreadSwitchWithDelay() that are currently scattered in the source.  There
aren't a lot of them but a few were entered in some heavily hit areas just to make sure that
things run smoothly.  The reason why I bring this up now is because I hit a "CPU Hog" error
on my NetWare server while trying to run the TESTMEM.c memory api tester.  After hacking in
a call to NXThreadYield, everything seemed to work much better.

thanks,
Brad

>>> "William A. Rowe, Jr." <wrowe@rowe-clan.net> Monday, July 30, 2001 2:44:30
PM >>>
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?

Bill



Mime
View raw message