sending thread exceptions (was Re: RELEASED Python 2.3.1)
aleax at aleax.it
Sat Sep 27 18:04:15 CEST 2003
> 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"
> 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,
> 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
More information about the Python-list