Josiah Carlson <[EMAIL PROTECTED]> writes: >> It's not realistic to expect sys.setcheckinterval be implementable on >> other runtimes. > > The 'raise an exception in an alternate thread' functionality is a > CPython specific functionality. If you believe that it could be > implemented in all other runtimes, then you missed the discussion that > stated that it would be impossible to implement in Jython.
Indeed both are hard to implement on some runtimes. I believe there are runtimes where asynchronous exceptions are practical while blocking context switching is not (e.g. POSIX threads combined with Unix signals and C++ exceptions). In any case, blocking switching the context to any other thread is an overkill. It's hard to say how sys.setcheckinterval should behave on truly parallel runtimes, while the semantics of blockable asynchronous exceptions doesn't depend on threads being dispatched sequentially. >> Also, it doesn't provide a way to unblock asynchronous exceptions until >> a particular blocking operation completes. > > I thought the point of this 'block asynchronous exceptions' business > was to block asynchronous exceptions during a particular bit of code. > Now you are saying that there needs to be a method of bypassing such > blocking from other threads? No, I'm talking about specifying the blocking behavior by the thread to be interrupted. It makes sense to wait for e.g. accept() such that asynchronous exceptions are processed during the wait, but that they are atomically blocked as soon as a connection is accepted. Unfortunately it's yet another obstacle to some runtimes. Yet another issue is asynchronous "signals" which don't necessarily throw an exception but cause the computation to react and possibly continue (e.g. suspend a thread until it's resumed). > Yes, it can be. You can add a lock to each thread (each thread gets its > own lock). When a thread doesn't want to be interrupted, it .acquire()s > its lock. When it is OK to interrupt it, it .release()s its lock. When > you want to kill a thread, .acquire() its lock, and kill it. This works almost well. The thread sending an exception is unnecessarily blocked; this could be solved by starting another thread to send an exception. And it doesn't support the mentioned unblocking only while waiting. The problem is that there is no universally recognized convention: I can't expect third-party libraries to protect their sensitive regions by my mutex. Without an agreed convention they can't even if they want to. My design includes implicit blocking of asynchronous exception by certain language constructs, e.g. by taking *any* mutex. Most cases of taking a mutex also want to block asynchronous signals. I'm surprised that various runtimes that I would expect to be well designed provide mostly either unsafe or too restricted means of asynchronous interruption. http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html http://www.interact-sw.co.uk/iangblog/2004/11/12/cancellation -- __("< Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
