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 Thu, 01 Jan 1970 00:00:00 GMT
On Thursday, 25 May 2000, wrote:
> 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.

Interesting idea. Are you suggesting something like the following? 

void winnt_pre_config()
    if (running_as_service) {
        address_of_main_fiber = ConvertThreadToFiber();
        address_of_dispatcher_fiber = CreateFiber(dispatcher_fiber_proc);
        /* all other pre-config processing */

int dispatcher_fiber_proc()
     * entire thread blocks in above function forever and becomes the service
     * control dispatcher

void service_main()
    /* save the service name somewhere if we need it */
     * the first fiber in the primary thread now runs in this thread's context

This would have the primary thread blocking in StartServiceCtrlDispatcher, 
and the main function's fiber resuming execution in the context of the thread 
that the SCM started to enter ServiceMain.

Sounds a lot like the longjmp solution to me - I'd prefer that different 
units of execution that started in different threads didn't need to be
scheduled manually if at all possible. We'd also have to add all the fiber 
functions to the late binding code because they're not present on Win95. It
sounds like it will cause almost as much work as it saves (not much either 
way), plus I'm a fan of simplicity. 

If I misunderstood your suggestion, please correct me. 

The one thing I do like about this solution (and the longjmp one for that 
matter) is that we don't have an idle (wasted) thread in the process. I 
really don't think this is a big loss though, considering the extra work
needed to support fibers and that the memory manager should swap it to disk. 

> 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.

There is no way to make a thread out of a fiber. The closest you can get is 
to create another thread, convert it to a fiber, and schedule the first fiber
to run in the new thread's context. 

> 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() ).

No. When a fiber function exits, the thread that scheduled it to run exits
also. To achieve what you describe, you need to either 
a) save the return code in global storage and explicitly re-schedule the 
   original fiber; or
b) spawn another thread and exit the fiber with ExitThread(return_code).

If there's another way, please enlighten me :-)

> 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.

Sort of, but not exactly. This is a simple example with one thread and three 
fibers. Our situation involves at least two threads, one being blocked in a 
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. 

I'd rather stick with a solution based on additional threads unless, as Bill
R. mentioned, it is unworkable.


This message was sent through MyMail

View raw message