httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <bh...@pobox.com>
Subject Re: Pools and Threads and Errors
Date Fri, 15 Jan 1999 00:40:42 GMT
Dean Gaudet writes:
>On Thu, 14 Jan 1999, Ben Hyde wrote:
>> TerminateThread is this operation on NT.  The manual does warn that it
>> is a dangerous (duh).  It reports you have to do the cleanups your self.
>> including those for code you didn't write (i.e. DLLs including kernal32).
>
>i.e. not worth considering :)

An OS is built of shared DLLs that can not handle the murder/suicide
of a few processes and threads then they are in pretty deep ain't
they.

>> The timeout I'm concerned about is the one were a module callback goes 
>> out to lunch because they will.  The lack of designing for this case
>> in NT programs seems to me to explain a lot about why they are forever
>> going out to lunches from which they never to return.
>
>Yeah but there's no portable solution to this problem that I'm aware of. 

OK, I guess I'm drifting back toward the never EVER destroy a thread
model.  I sure have a hell of a time staying in that mind set.

>Even on unix in single threaded apache we can't solve this problem.  We
>can't take a SIGALRM in third-party code, because it's frequently not
>ready to see EINTR or anything else like that.  It's certainly not ready
>for a longjmp().  Even though we do this, we just get lucky because we
>only lose one process when it messes up.
>
>If a site has such a braindead module then they can build their apache
>without threads (unless they happen to be so unfortunate as to be using
>NT).  

Blame the victim eh?  Module lock up because the hang on some down
stream resource as much as on because they get to contemplating their
navel.

>I've always been advocating that we continue to support the
>multiprocess model.

We are allowed to destroy processes right? :-).

If so we still have to design enough stuff to allow things to unwind
during that destruction - happy day all the work none of the noble
consequences (like a real error handling scheme).

>> I'm shopping for a consensus that we do or don't EVER destroy threads,
>> either outcome leads to consequences.
>
>We don't, we can't do it if we want to remain portable. 

I'm not convinced it has anything to do with "portable" but rather
it has to do with the how hopeless interrupting/unwinding a 3rd
party piece of code is.

>I'd like to be corrected if I'm wrong though. 

Well there is a split the difference design that says if you
want to leverage 3rd party code you have to warranty that you've
got the unwinding under control, otherwise we nuke the entire
process for your own "good" if you run over budget.

 - ben

Mime
View raw message