[Python-3000] threading, part 2

[Josiah Carlson]

Threading is already difficult enough to do 'right' (see the dozens of
threads discussing why this is really the case), and designing software
that can survive the raising of an exception at any point makes
threading even more difficult.

I believe that you are attempting to design an interface to make this
particular feature foolproof.  I think that such is a mistake; killing a
thread should be frought with gotchas and should be documented as "may
crash the runtime".  Offering users anything more is tantamount to
encouraging its use, which is counter to the reasons why it is not
available via a standard threading.function call: because it shouldn't
be used at all, except by people who know what the heck they are doing.

I believe that if a user cannot design and implement their own system to
handle when a thread can be killed or not to their own satisfaction,
then they have no business killing threads.


 - Josiah

"Marcin 'Qrczak' Kowalczyk" <qrczak at knm.org.pl> wrote:
> Josiah Carlson <jcarlson at uci.edu> 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
>    \__/       qrczak at knm.org.pl
>     ^^     http://qrnik.knm.org.pl/~qrczak/
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/jcarlson%40uci.edu