httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Spero <...@tipper.oit.unc.edu>
Subject Re: Removing ap_dummy_mutex from API
Date Sat, 03 Oct 1998 01:46:36 GMT
This is also why garbage collection is so useful; all the conservative garbage
collectors support finalizers, so you can collect OS resources as well as just
memory. In Posix threads, the thread can chose whether to accept cancels or not. The
two techniques combined make this problem a lot less hassle.

Simon

Dean Gaudet wrote:

> Yup, and this is also why multiprocess models are still interesting :)
>
> Dean
>
> On Fri, 2 Oct 1998, Ben Hyde wrote:
>
> > Dean Gaudet writes:
> > > ... race conditions due to signals that I don't think are
> > >solveable.  For example, if you take a signal inside a 3rd party
> > >library... you're toast.  You can't expect it to continue properly (some
> > >do, some don't), and you can't longjmp out of it because it could leak
> > >resources.  The only way around it is to not take the signal.
> >
> > That does seem to be the industry solution.  Nobody (aka 3rd party
> > code) implemented interrupt handling right in their code and meanwhile
> > longjmp is rarely dependable either.  So we all end up deciding to
> > forswear interrupts.
> >
> > Tuning in latter...
> > Mr. Application say:
> >  "What happens when a thread/process gets stuck, errors, or runs out of time?"
> > Mr. OS say:
> >  "You could have another thread kill it."
> > A: "Can I clean up?"
> > O: "Not really, but the thread that kills it can."
> > A: "Oh so I build my own stack of cleanup."
> > O: "You got it."
> > A: "wonderful"
> > O: "Don't worry the OS data structures will be reclaimed."
> >
> > Good thing we got those pools and with their cleanup routines per thread in 2.
> >
> >  - ben
> >


Mime
View raw message