httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Platform Specific MPM Design Questions
Date Thu, 25 May 2000 04:17:55 GMT

In a message dated 00-05-25 00:30:49 EDT, William Rowe writes...

> Ok... the remaining problem is the return; from service_main,
> and it looks like we need to block there as well for the
> service to completely terminate.  If we block in service_main,
> we can idle the thread while Apache lives.
> I'll try your idea first, and then return to my original
> concept only if this fails horribly.

After looking a little closer at what it is you are really trying to
do here at kickoff time I think what you have here is a classic 
situation for using 'Fibers' instead of threads.

'Fibers' are unique to Windows ( which is the only OS you are
trying to solve the Service startup for anyway ) and they would
give you exactly what you want including full access to the
primary Tls ( Thread Local Storage ) for the lifetime of the fiber.

Fibers are actually very cool... I wish pthreads had them.

A fiber is 'like' a thread but it allows you to 'peel off' and start 
another thread of execution that actually shares the exact same
Tls and resources as the thread that launched the fiber.
The overhead to create one is as low as it can be ( much less than
a thread and much much much less than a process ).

After you call 'CreateFiber()' ( any number of times like setting the
horses into the gate ) You can then just fire one or more off at
once with 'SwitchToFiber()'.

Fibers are unique in that they instantiate themselves but since
they share ALL the resources of the parent thread ( Including the
CPU and the clock ) they won't start 'executing' until you allow them to.

Once all your 'Fibers' are created and running they can all control
each other and you don't even need to use any 'wait' objects like you
would with normal threads.

When the fiber(s) are 'done'... your IP counter is exactly where it
was before the first call to 'SwitchToFiber' in your main thread
of execution ( if that's the way you want to do it ).

The really neat trick is that you can use turn any FIBER into a real
THREAD or vice versa with calls to 'ConvertThreadToFiber()' and such.

This might be a neat trick for starting a 'Service' in the manner you
are thinking of. A fiber might be the best way to hold up 'main()' and
do whatever and if all seems to be OK you can still start the Service
normally on the fiber ( The Service Control Manager isn't going to know 
it's a fiber and not a thread at that point ) and if you want to keep the 
itself that started the Service because all was deemed AOK then just 
turn that fiber into a real 'Thread' and, as they say in the tri-state
area... FUUHGETABOUTIT while it happily 'runs' the Service.

If it FAILS while trying to work things out with the SCM then no
harm done... the 'Fiber' can terminate without ever actually becoming
a 'real' thread and you end up right where you want to be with
error code in hand ( back in main() ).

A lot of MSIE and Internet Information Server itself is based on
Fibers. You can see them with an ICE machine during runtime 
when all these 'threads' beging to appear but they actually all share 
the same exact resources and Tls. They don't have to jump through 
hoops like shared memory as one would often need to do with
'CreateThread()' and the overhead remains as low as it can get.

There are tons of Fiber samples in the MSVC SDK. One is a 
entitled 'Fibers Sample: Fiber-based File Copy Operations'
and it is actually 're-enters main()' in the same way I believe
you wish to do here to get a Win32 Service up and kicking.

Just a thought. Anything else might be a little like going to
New York via China. The fiber approach would probably also handle
the other things this 'startup' scheme will have to deal with as
well such as... what if the Service is already running and has
to be 'stopped' and 'started' again before the jump-back, etc.

View raw message