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