[asterisk-dev] Pthread wrapper updates

[Tim Panton]

On 4 Nov 2006, at 12:18, SF Markus Elfring wrote:

>
>> So - sure -  abort the action to protect the rest of the process,  
>> but don't
>> kill the process just because one thread is stuck.
> Can you imagine that the "stuck" thread can prevent the process to  
> make further progress because mutual exclusion is required to keep  
> the internal data structures in consistent state?

Yes, of course, the box will slowly grind to a halt. In the meanwhile  
the threads that already have their
resources allocated can continue providing several minutes of  
possibly invaluable service.

>
>
>> I guess it depends on what the scope of 'abort' is - thread ok -  
>> process not so good.
> I suggest to fix faulty software before the "catastrophe" will happen.

Yes, absolutely, thats always the best option and we should strive  
for it. However, as I said,
this is engineering, so we need to be tolerant of faults if we can.

>
> Have you got different approaches besides fault tolerance or load  
> balancing for security handling and application safety in mind?
> The current source code seems to have got the potential to set the  
> issue on fire before your own urgent phone call.

Probably :-) . I was addressing the general issue of aborting because  
a resource is deadlocked.

I spent a couple of years working of projects for the european space  
agency,
where you can't reach easily reboot because
your code is several light seconds away. In that environment you keep  
the coms/cmd channel
working at all costs.




Tim Panton

www.mexuar.net
www.westhawk.co.uk