On May 19, 11:31 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 11:36 AM, Roger Heathcote > > Fair point, but for sub processes that need to be in close contact with the > > original app, or very small functions that you'd like 100s or 1000s of it > > seems like a kludge having to spawn whole new processes build in socket > > communications and kill via explicit OS calls. I can't see that approach > > scaling particularly well but I guess there's no choice. > > It's not a kludge - the whole reason why killing a thread is undefined > and a "cardinal sin" is because it's in your own address space and you > can't guarantee anything about how it left things when you killed it. > You simply can't have it both ways. If you want to be able to safely > and sanely kill an uncooperative thread (*especially* third party code > you don't control) you have to isolate it from your address space, and > this means a process. This is a fundamental problem with the entire > idea of shared-state concurrency. For the record, you can't use 1000s > of threads either - if you really need 1000s of concurrent things > running you need to re-think your concurrency model and possibly your > choice of languages and environment.
Strictly speaking, you CAN use 1000s of threads, but it requires some special effort. It's not a good idea though, at least for the near future. If you want to kill a thread you have to do it cooperatively, and for the effort required to get that right you might as well make the whole thing event-driven. > The messiness of the real world is *why* you should use processes, not > a reason to avoid them. > > > Does anyone think it likely that the threading module (and threading in > > general) will be improved and augmented with features like timeouts and > > arbitrary threadicide in the next year or two? Seems there's little scope > > for tapping the power of the current generation of multiple cores with the > > current pythons, tho I appreciate breakneck speed has never been a design > > objective it looks like multicore is set to be the next generation PC > > architecture. > > They absolutely should not be. Adding an API which can't work in the > general case and is dangerous even when it can work does not do anyone > any favors. I agree, if it's not safe there's no point adding it. However, if you change the parameters a little bit.. it's quite possible to redefine many blocking functions as cooperative cancellation points. This is the approach I take with python- safethread, and it should satisfy most purposes. -- http://mail.python.org/mailman/listinfo/python-list
