sending thread exceptions (was Re: RELEASED Python 2.3.1)

[Alex Martelli]

Dominic wrote:

> 
> Well, first of all I agree with you that
> a more traditional approach using queues
> is better and more predictable.
> 
> And yes on a single CPU machine I was
> thinking about stopping all "low priority"
> threads.
> 
> This is somehow creaky and fragile but
> you don't need a thread per "task" as
> in your queue based alternative.

Queues don't make you need a thread per task: you
can perfectly well have threads from a pool peeling
tasks of a queue of tasks -- that's a frequent use,
in fact.


> So you could have 3000 "tasks" and
> one thread e.g.
> However every "task" would need to recover
> from it's injected exception which
> is kind of unpredictable and hard to program.
> 
> I would not use such an architecture ;-)

Me neither -- exceptions can arrive at any time, and
recovering and restarting a task under such conditions
is frighteningly hard.  Much easier to have all tasks
coded as loops with reasonably frequent checks on e.g.
a lock, if you do need to temporarily suspend them all
to leave CPU available for an occasional high-priority
task -- this way the checks come when the task is in
a "reasonable", "restartable" state, implicitly.


> Now to the delay:
   ...
> As you can see it takes about 7 seconds until the
> exception is injected.

Offhand you seem to be testing your console drivers and the
C runtime library interface to them, much more than you're
testing Python.  The test I posted doesn't use the console
in such critical junctures -- admittedly it does use time.sleep,
one does have to waste time in SOME way without melting the
CPU, but that still feels less artificial to me than your
console-based minuet.


Alex