"Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> wrote: > > Josiah Carlson <[EMAIL PROTECTED]> writes: > > > There is already a way of making Python source execution atomic with > > respect to other Python code [1]. > > 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. As such, because both are CPython specific features, I don't see a problem with using both if you are going to be using one of them. > 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? > > If you don't want random exceptions being raised in your threads, then > > don't use this method that is capable of raising exceptions somewhat > > randomly. > > It's like saying "if you don't want integer addition overflow, then > don't do addition". No. Integer addition is a defined feature of the language. Raising exceptions in an alternate thread is a generally unsupported feature available to CPython, very likely not implementable in most other runtimes. It has previously been available via ctypes, but its previous non-use is a function of its lack of documentation, lack of cytpes shipping with base Python, etc. > I do want asynchronous exceptions, but not anywhere, only in selected > regions (or excluding selected regions). This can be designed well. 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. In effect, the above would be what is necessary to give you what you want. It can easily be defined as a set of 3 functions, whose implementation should be left out of the standard library. Including it in the standard library offers the illusion of support (in the 'this language feature is supported' sense) for raising an exception in an alternate thread, which is not the case (it is available, but not supported). - Josiah _______________________________________________ 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
