httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: Pools and Threads and Errors
Date Thu, 14 Jan 1999 22:03:19 GMT

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 :)

> >If you look at how we currently use timeouts, we use them to get back from
> >network/pipe reads and writes.  That's pretty easy to implement via select
> >under unix (and I know it can be done under NT, I just don't know the
> >mechanism -- NSPR implements it).  The NSPR port adds a timeout parameter
> >to BUFF, and all reads or writes on that BUFF respect the timeout.
> Yes all I/O operations should time out.  Presumably when BUFF get that
> a timeout it marks the BUFF as dead in some sense?

It calls the previously unused error handler for the BUFF, which gives the
user a chance to do something special.  I forget exactly what I did. 

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

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).  I've always been advocating that we continue to support the
multiprocess model. 

> 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'd like to be corrected if I'm wrong though. 


View raw message