threading: how to kill a (possibly blocked) thread?

[David Bolen]

rturpin at my-deja.com writes:

>   set_interrupt(8, funcCallBack)
> 
> Then, funcCallBack gets invoked every 8 seconds,
> interrupting what the thread is doing, and returning
> to the interrupted code when the function returns.
> Unfortunately, I don't see such a facility in the
> library.

The issue is most likely that there's nothing I'm aware of in that
vein that is at all portable - also the ability to interrupt a pending
activity can be problematic.  Under Unix for example, not all I/O
calls are interruptable and they also don't all restart nicely even if
you may have SA_RESTART on the signal in question.  Then there's the
whole delivery of signals/interrupts to other than the main thread
problem on many systems.

I don't disagree with the sentiment, and have found myself wishing I
could just block in an operation in a thread more than once - just
trying to explain why it likely isn't in Python itself, nor likely to
be in the near future.

But with that said, I've got plenty of multi-threaded code that does
just fine with the "don't ever really block indefinitely" model, in
terms of addressing the original poster's question.

> > .. The main thread code should then check the event
> > object periodically and exit nicely if it is set.
> 
> Except for certain kinds of processing, such as FSMs,
> this gets REAL ugly REAL fast. It also fails to protect
> against the very things for which you want a guard,
> i.e., external events that never occur.

I'd need a specific example, but I'd think an FSM would be ideal for
this model, since by its nature you have some primary loop which is
making the state automaton decisions, and thus you should have a key
opportunity to deduce that it's time to exit.  And if you're just
sitting in a state without anything to do, well spend the time blocked
on some event that can be woken up should an exit request come in.

I'm not sure I follow the last sentence because I'm referring to
coding so that you never block indefinitely, but instead use whatever
mechanisms may be available to wait for the event you want but in some
timed manner so you get the occasion to check for an exit every once
in a while.  And that's specifically to guard against the external
event never occurring.

Typically the most troubling can be I/O operations that don't support
any way to timeout or monitor the status without blocking.  Often,
I've found that this is because the portable approach is more limited
than the native approach, which can be discouraging since most other
aspects of Python threading are so clean and portable.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/