sending thread exceptions (was Re: RELEASED Python 2.3.1)
Alex Martelli
aleax at aleax.it
Fri Sep 26 06:18:41 EDT 2003
Peter Hansen wrote:
...
> I know this won't meet the standard, but what about a use case
> involving "actually running (as opposed to debugging) possibly
> buggy (non-terminating) code". This could come up in cases such as
> our embedded Linux product, which is supposed to be a long-running
> process.
>
> And yes, to make it clear, I am actually suggesting the possibility
> that the product could ship with buggy code that could cause that
> condition. It does happen in the real world... more often than
> anybody normally cares to admit. More often with multi-threaded
> applications than is good for anyone, of course. Sometimes,
Yep. And even more often, the buggy code will involve race
conditions -- unsynchronized access to variables from >1 thread --
which will make you wail long and loud. Which is just part of
why using multiple processes, on a platform such as Linux (where
forking a process isn't the end of the world in terms of
performance), is so often preferable to using multiple threads
within a single process: the operating system gives you far better
support for isolating faults, ensuring communication between
processed DOES go "through the channels", terminating errant
processes, and so on, and so forth (as a cherry on top, if you're
on a multi-CPU machine you'll also get to exploit all of your
CPU's, while Python-coded threaded wouldn't do that:-).
I try to limit my multithreaded architectures to VERY simple
structures, based mostly on Queue's for inter-thread cooperation.
Whenever hairy issues emerge -- I try to move to multi-process
architectures instead, at least when I know I will be running
on an OS with decent support for processes. Admittedly, that
is not _always_ possible (sometimes one does have to run under
Windows, for example, with excellent support for threads but
rather heavy-weight processes); thus, it IS nice to be able to
try and interrupt another thread (it IS just a "try": if the
buggy code is looping forewher within a try/except that just
keeps looping when you interrupt it, you're hosed anyway -- it
still isn't anywhere as solid as a multi-process architecture).
Remember, I was among the *paladins* of the new functionality;-).
However, I do think it's crucial that it be used only as a very
last resort, NOT in the 99.99% of cases which are best covered
by other architectures...
> Yes, I'm reaching somewhat. Although I actually would like that
> feature, even if it were available it would be quite some time
> before implementing it would be high enough on the list of priorities
> to bother. And wait! It _is_ available, just not directly, so I
> can hardly complain. :-)
>
> Point mostly taken...
Sure, we did end up having the feature -- just a fingerbreadth away
from the average programmer's reach;-). Anybody who truly really
needs it IS doing stuff much more complicated than average, anyway;-).
Alex
More information about the Python-list
mailing list