On Tue, Apr 8, 2008 at 4:46 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Adam Olsen wrote: > > Killing threads at arbitrary points really is that dangerous. > > I'm not talking about killing an arbitrary thread, but > a particular thread that I've designed with the idea of > killing it in mind. > > And I'm not really talking about killing it, either, > just having a way of tapping it on the shoulder and > getting its attention whatever it happens to be doing. > > I don't believe that's an outrageously unreasonable > thing to want to be able to do. > > To be precise, what I have in mind is this: > > 1) A way of causing an exception to be raised asynchronously > in another thread. > > 2) Such exceptions would be automatically blocked in > a finally clause. > > 3) There would be a way of explicitly blocking them > around a section of code, e.g. using a context manager. > > 4) If it makes anyone feel any better, they could be > blocked by default until explicitly enabled by the > thread concerned. > > 5) When a thread dies, either: > > a) Any locks it is holding are automatically released, > or > > b) An exception is raised in the main thread if it dies > while holding any locks (since this indicates a programming > error, i.e. the thread failed to clean up after itself > when receiving an asynchronous exception). > > Can anyone point to a reason it would be difficult to write > well-behaved threaded code in the presence of these features?
I think what bothers me is I want the restrictions to be enforced upfront, so any violation produces a clear exception, whereas your proposal does not diagnose them until later. As a counter proposal, you could either forbid acquiring locks, or have them implicitly block the asynchronous exception. It's also worth noting that we have very little info on how a given operation is subdivided. I personally think that's a good thing - if you need it, you're doing something wrong. I have only two use cases in mind: 1. CPU bound tasks that can't be subdivided, such as 10**10**10 2. Arbitrary code in the interactive interpreter The latter can't be done sanely. It's simply accepting that between a hung interpreter and a possibly (but unlikely) corrupted user program, we'd rather risk corrupting the user program. -- Adam Olsen, aka Rhamphoryncus _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
