John Nagle wrote: > Aahz wrote: > >> In article <[EMAIL PROTECTED]>, >> Carl J. Van Arsdall <[EMAIL PROTECTED]> wrote: >> My point is that an app that dies only once every few months under load >> is actually pretty damn stable! That is not the kind of problem that >> you are likely to stimulate. >> > > This has all been so vague. How does it die? > Well, before operating on most of the data I perform type checks, if the type check fails, my system flags an exception. Now i'm in the process of finding out how the data went bad. I gotta wait at this point though, so I was investigating possibilities so I could find a new way of throwing the kitchen sink at it.
> It would be useful if Python detected obvious deadlock. If all threads > are blocked on mutexes, you're stuck, and at that point, it's time > to abort and do tracebacks on all threads. You shouldn't have to > run under a debugger to detect that. > > Then a timer, so that if the Global Python Lock > stays locked for more than N seconds, you get an abort and a traceback. > That way, if you get stuck in some C library, it gets noticed. > > Those would be some good basic facilities to have in thread support. > I agree. That would be incredibly useful. Although doesn't this spark up the debate on threads killing threads? From what I understand, this is frowned upon (and was removed from java because it was dangerous). Although I think that if there was a master or control thread that watched the state of the system and could intervene, that would be powerful. One way to do this could be to use processes, and each process could catch a kill signal if it appears to be stalled, although I am absolutely sure there is more to it than that. I don't think this could be done at all with python threads though, but as a fan of python threads and their ease of use, it would be a nice and powerful feature to have. -carl -- Carl J. Van Arsdall [EMAIL PROTECTED] Build and Release MontaVista Software -- http://mail.python.org/mailman/listinfo/python-list