running functions

[Donn Cave]

Quoth Grant Edwards <grante at visi.com>:
| On 2005-11-18, Scott David Daniels <scott.daniels at acm.org> wrote:
| > Gorlon the Impossible wrote:
| >
| >> I have to agree with you there. Threading is working out great for me
| >> so far. The multiprocess thing has just baffled me, but then again I'm
| >> learning. Any tips or suggestions offered are appreciated...
| >
| > The reason multiprocess is easier is that you have enforced
| > separation. Multiple processes / threads / whatever that share
| > reads and writes into shared memory are rife with
| > irreproducible bugs and untestable code.
|
| There can be problems, but you make it sound way worse than it
| really is.  I've been doing threaded SW for a lot of years
| (yikes! almost 25), and it's just not that hard to deal with
| shared objects/variables -- especially in Python with its GIL.
|
| I think it's easier and more intuitive than forking.
|
| I've written a lot of (admittedly not huge) Python programs
| using threading (some with 30-40 thread), and I don't remember
| ever tripping over anything significant.  I think dealing with
| shared objects is easier than figuring out how to do
| inter-process communications using sockets or Posix shared
| memory or whatnot.  It's not difficult if you don't have to do
| any communication between processes, but in that case, shared
| objects aren't a problem either.

To understand the point behind this, it's important to understand
what easy and difficult are about here.  Are we talking about easy
to get something done?  Easy to get something absolutely reliable?
Easy to screw up?

The point is not that it's hard to import the threading module and
fire off a thread to do something.  On the contrary, if anything
maybe it's too easy.  The thing that's supposed to be difficult is
predictable, reliable execution, in in principle because of a
compounding effect on the number of possible states.

It should be scary.  Whether it should be prohibitively scary is
the kind of abstract debate that will never really be resolved here.

I got into BeOS when it came out a few years back, and learned to
program in Python to its native UI, where each window has its own
thread.  It works fine for me, and I personally support the decision
to do it that way, but later there was a school of thought, including
some ex-Be engineers among the proponents, that held it to be a big
mistake.  Apparently this was after all a common pitfall for application
developers, who would release code that could deadlock or go wrong
in various ways due to unanticipated thread interactions.  All of
these application developers were working in C++, and I'm sure that
made them a little more vulnerable.  Thank heavens Python isn't
capable of real concurrent execution, for one thing, and also it's
surely easier to put together generic functions for queueing and
that sort of thing, so I could afford to be more disciplined about
sharing data between threads.  But in the end there were a lot more
of them, their applications were bigger or more adventurous and more
widely used, so there were a lot of opportunities for things to happen
to them that have never happened to me.  As I said, I thought their
design was good, but maybe they just didn't get the word out like
they should have - that threads are scary.

	Donn Cave, donn at drizzle.com

(posting this from a Python/BeOS API newsreader)