httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Costello" <>
Subject RE: Platform Specific MPM Design Questions
Date Sat, 27 May 2000 02:56:54 GMT
On Saturday, 27 May 2000, wrote:
> >  If I misunderstood your suggestion, please correct me.
> The Fiber approach has no MAJOR advantage over multi-thread and
> synchronization objects for Apache startup. It was just a suggestion.

Okay. It made me re-check everything I knew about fibers, and I learnt a lot
from it. Thanks.

> The code line count would probably be the same... but see below about
> how this might be a good time to add Fiber support to Apache Win32 if it
> wants to be a 'serious' contender with IIS. There are other places where
> having the Fiber support onboard can make a BIG difference to
> a multi-threaded Win32/64 HTTP server.

Such as...? It sounds like you have specific suggestions on how to improve
the server. If so, grab a fresh copy of the source, and send in a patch.

Apache-2.0 on NT is already significantly faster than 1.3, mainly due to
better use of operating system facilities (eg. TransmitFile and I/O
Completion Ports), and the fact that APR and the MPM use Win32 calls instead
of compatability library calls.

Or did you mean "contender with IIS" on grounds other than performance? Given
that you mentioned performance near the end of your original message - I'm
assuming that's what you meant.

> A Fiber is already a thread no matter what. The only time it is not acting
> as a 'pure' thread is when you have several fibers going and you are
> doing the pre-emptive scheduling of the mulitple fibers yourself.

No, a fiber is not a thread - similar to how a thread is not a process. A
fiber is scheduled within a thread's context. The distinction was important
when I was trying to figure out how you intended using fibers to solve our
NT service startup problem. And fibers are co-operatively scheduled.

> The following is a full working example ( albeit, simple ) of what
> I really meant. The secondary 'fiber' has the job of running some
> 'startup' code or whatever and, if all goes well, it converts itself
> back into a 'thread' and kills off the primary fiber so nothing ends
> up 'hanging around' in memory. If something goes wrong then it acts
> just like a 'function call' that returns an error code.

Example of what? This has nothing to do with Apache's NT service startup code
except that one variable is called "apache_startup_failed" and there's a
comment saying "apache startup code goes here". It completely ignores the
aim of safely maintaining one primary execution path, while allowing the SCM
to reenter the application.

> This will actually compile and run...

But it's not relevant.

> >  system call when we want to schedule one of its fibers. I think this
> >  particular situation calls for a bit more thought than the sample.
> A little. Remember that any thread can control any other thread and
> even kill it off. It is not considered 'polite' but it works just fine.

You're kidding, aren't you? There is no way killing a thread (in Win32) works
"just fine" - especially in a server application. And I quote:

"TerminateThread is used to cause a thread to exit. When this occurs, the
target thread has no chance to execute any user-mode code and its initial
stack is not deallocated. DLLs attached to the thread are not notified that
the thread is terminating.
For example, TerminateThread can result in the following problems:
 * If the target thread owns a critical section, the critical section will not
   be released.
 * If the target thread is executing certain kernel32 calls when it is
   terminated, the kernel32 state for the thread's process could be
 * If the target thread is manipulating the global state of a shared DLL,
   the state of the DLL could be destroyed, affecting other users of the DLL.

What is your point?

> It might not be the best idea for the whole 'startup' thing but if the
> new Apache wants to do some serious cranking in the Win32/64 environment
> it might be worth making sure a base build includes all the 'Fiber' support
> since there are only about a thousand other places in a multi-thread
> HTTP Server where Fiber support can make a real speed difference.

Umm, I thought the original purpose of this email thread was to solve this
"whole startup thing".

View raw message