running functions

[Gorlon the Impossible]

Hello
I'm not sure how to phrase this question. I have a Python function
that sends MIDI messages to a synth. When I run it, I of course have
to wait until it is finished before I can do anything else with
Python. Is it possible to run this function and still be able to do
other things with Python while it is running? Is that what threading
is about?

[Grant Edwards]

On 2005-11-16, Gorlon the Impossible <me********@yahoo.com> wrote:

I'm not sure how to phrase this question. I have a Python function
that sends MIDI messages to a synth. When I run it, I of course have
to wait until it is finished before I can do anything else with
Python. Is it possible to run this function and still be able to do
other things with Python while it is running?
Yes.
Is that what threading is about?

Exactly. Take a look at the "treading" module:

http://www.python.org/doc/current/li...threading.html

--
Grant Edwards grante Yow! BRILL CREAM is
at CREAM O' WHEAT in another
visi.com DIMENSION...

[Grant Edwards]

On 2005-11-16, Gorlon the Impossible <me********@yahoo.com> wrote:

I'm not sure how to phrase this question. I have a Python function
that sends MIDI messages to a synth. When I run it, I of course have
to wait until it is finished before I can do anything else with
Python. Is it possible to run this function and still be able to do
other things with Python while it is running?
Yes.
Is that what threading is about?

Exactly. Take a look at the "treading" module:

http://www.python.org/doc/current/li...threading.html

--
Grant Edwards grante Yow! BRILL CREAM is
at CREAM O' WHEAT in another
visi.com DIMENSION...

[Ben Finney]

Gorlon the Impossible <me********@yahoo.com> wrote:

I'm not sure how to phrase this question. I have a Python function
that sends MIDI messages to a synth. When I run it, I of course have
to wait until it is finished before I can do anything else with
Python. Is it possible to run this function and still be able to do
other things with Python while it is running? Is that what threading
is about?

Threads are a complex answer. Subprocesses are a less complex answer.

(good sigmonster, have a biscuit)

--
\ "I have yet to see any problem, however complicated, which, |
`\ when you looked at it in the right way, did not become still |
_o__) more complicated." -- Paul Anderson |
Ben Finney

[Ben Finney]

Gorlon the Impossible <me********@yahoo.com> wrote:

I'm not sure how to phrase this question. I have a Python function
that sends MIDI messages to a synth. When I run it, I of course have
to wait until it is finished before I can do anything else with
Python. Is it possible to run this function and still be able to do
other things with Python while it is running? Is that what threading
is about?

Threads are a complex answer. Subprocesses are a less complex answer.

(good sigmonster, have a biscuit)

--
\ "I have yet to see any problem, however complicated, which, |
`\ when you looked at it in the right way, did not become still |
_o__) more complicated." -- Paul Anderson |
Ben Finney

[sjdevnull]

Gorlon the Impossible wrote:

Hello
I'm not sure how to phrase this question. I have a Python function
that sends MIDI messages to a synth. When I run it, I of course have
to wait until it is finished before I can do anything else with
Python. Is it possible to run this function and still be able to do
other things with Python while it is running? Is that what threading
is about?

Threading's a good answer if you really need to share all your memory.
A multiprocess solution is probably preferrable, though it depends on
the architecture.

It may be possible to do it in a single process (if, say, the MIDI
synth supports waitForMultipleObjects, select, async I/O, or an
equivalent thereof) without blocking.

[sjdevnull]

Gorlon the Impossible wrote:

Hello
I'm not sure how to phrase this question. I have a Python function
that sends MIDI messages to a synth. When I run it, I of course have
to wait until it is finished before I can do anything else with
Python. Is it possible to run this function and still be able to do
other things with Python while it is running? Is that what threading
is about?

Threading's a good answer if you really need to share all your memory.
A multiprocess solution is probably preferrable, though it depends on
the architecture.

It may be possible to do it in a single process (if, say, the MIDI
synth supports waitForMultipleObjects, select, async I/O, or an
equivalent thereof) without blocking.

[Cameron Laird]

In article <11*************@corp.supernews.com>,
Grant Edwards <gr****@visi.com> wrote:

On 2005-11-16, Gorlon the Impossible <me********@yahoo.com> wrote:

I'm not sure how to phrase this question. I have a Python function
that sends MIDI messages to a synth. When I run it, I of course have
to wait until it is finished before I can do anything else with
Python. Is it possible to run this function and still be able to do
other things with Python while it is running?

Yes.

Is that what threading is about?

Exactly. Take a look at the "treading" module:

http://www.python.org/doc/current/li...threading.html

[Cameron Laird]

In article <11*************@corp.supernews.com>,
Grant Edwards <gr****@visi.com> wrote:

On 2005-11-16, Gorlon the Impossible <me********@yahoo.com> wrote:

I'm not sure how to phrase this question. I have a Python function
that sends MIDI messages to a synth. When I run it, I of course have
to wait until it is finished before I can do anything else with
Python. Is it possible to run this function and still be able to do
other things with Python while it is running?

Yes.

Is that what threading is about?

Exactly. Take a look at the "treading" module:

http://www.python.org/doc/current/li...threading.html

[Gorlon the Impossible]

On Thu, 17 Nov 2005 00:08:02 GMT, cl****@lairds.us (Cameron Laird)
wrote:

In article <11*************@corp.supernews.com>,
Grant Edwards <gr****@visi.com> wrote:

On 2005-11-16, Gorlon the Impossible <me********@yahoo.com> wrote:

I'm not sure how to phrase this question. I have a Python function
that sends MIDI messages to a synth. When I run it, I of course have
to wait until it is finished before I can do anything else with
Python. Is it possible to run this function and still be able to do
other things with Python while it is running?
Yes.

Is that what threading is about?

Exactly. Take a look at the "treading" module:

http://www.python.org/doc/current/li...threading.html

.
.
.
I don't agree, Grant (although I salute the brevity
of your follow-up), and a couple of other correspon-
dents have already posted follow-ups that begin to
explore the alternatives.

If I were pursuing this, the first question I'd have
for Gorlon is whether he's OK with a "fire and for-
get" model. By that, I mean to ask if it's OK to
send the MIDI message, and then return immediately
to other Python work, OR whether Gorlon also needs
to stay in contact with the MIDI handler, and
perhaps react especially when the MIDI handler
finishes with the specific message. That choice is
crucial in a good concurrency design.

'good concurrency design' LOL... I'm not that proficient at
programming in general or Python...
You bring up some interesting points, though. I am just learning and
experimenting with programming MIDI events at this level. My function
sends a series of MIDI note-on and note-off messages and that's it so
far. But, I am trying to learn more and working towards a sort of
'live-coding' set-up for musical performance. So, eventually I will
want to be able to control other synth parameters with MIDI messages
and be able to start and stop different kinds of control functions 'on
the fly' so to speak. I checked out the threading module and its
working for what I am trying to do at the moment, but I am open to
suggestions and eager to learn all I can about other options. Thanks
for taking the time to respond.
I would be interested in hearing more about the subprocess approach...

So, Gorlon, yes, threading is a prominent member of
the family of facilities that address situations like
yours. It's not the only one, though.

[Gorlon the Impossible]

On Thu, 17 Nov 2005 00:08:02 GMT, cl****@lairds.us (Cameron Laird)
wrote:

In article <11*************@corp.supernews.com>,
Grant Edwards <gr****@visi.com> wrote:

On 2005-11-16, Gorlon the Impossible <me********@yahoo.com> wrote:

I'm not sure how to phrase this question. I have a Python function
that sends MIDI messages to a synth. When I run it, I of course have
to wait until it is finished before I can do anything else with
Python. Is it possible to run this function and still be able to do
other things with Python while it is running?
Yes.

Is that what threading is about?

Exactly. Take a look at the "treading" module:

http://www.python.org/doc/current/li...threading.html

.
.
.
I don't agree, Grant (although I salute the brevity
of your follow-up), and a couple of other correspon-
dents have already posted follow-ups that begin to
explore the alternatives.

If I were pursuing this, the first question I'd have
for Gorlon is whether he's OK with a "fire and for-
get" model. By that, I mean to ask if it's OK to
send the MIDI message, and then return immediately
to other Python work, OR whether Gorlon also needs
to stay in contact with the MIDI handler, and
perhaps react especially when the MIDI handler
finishes with the specific message. That choice is
crucial in a good concurrency design.

'good concurrency design' LOL... I'm not that proficient at
programming in general or Python...
You bring up some interesting points, though. I am just learning and
experimenting with programming MIDI events at this level. My function
sends a series of MIDI note-on and note-off messages and that's it so
far. But, I am trying to learn more and working towards a sort of
'live-coding' set-up for musical performance. So, eventually I will
want to be able to control other synth parameters with MIDI messages
and be able to start and stop different kinds of control functions 'on
the fly' so to speak. I checked out the threading module and its
working for what I am trying to do at the moment, but I am open to
suggestions and eager to learn all I can about other options. Thanks
for taking the time to respond.
I would be interested in hearing more about the subprocess approach...

So, Gorlon, yes, threading is a prominent member of
the family of facilities that address situations like
yours. It's not the only one, though.

[Cameron Laird]

In article <bn********************************@4ax.com>,
Gorlon the Impossible <me********@yahoo.com> wrote:

[Cameron Laird]

In article <bn********************************@4ax.com>,
Gorlon the Impossible <me********@yahoo.com> wrote:

[Tom Anderson]

On Wed, 16 Nov 2005, sj*******@yahoo.com wrote:

Gorlon the Impossible wrote:

Is it possible to run this function and still be able to do other
things with Python while it is running? Is that what threading is
about?

Threading's a good answer if you really need to share all your memory. A
multiprocess solution is probably preferrable, though it depends on the
architecture.

I'm really curious about this assertion, which both you and Ben Finney
make. Why do you think multiprocessing is preferable to multithreading?

I've done a fair amount of threads programming, although in java rather
than python (and i doubt very much that it's less friendly in python than
java!), and i found it really fairly straightforward. Sure, if you want to
do complicated stuff, it can get complicated, but for this sort of thing,
it should be a doddle. Certainly, it seems to me, *far* easier than doing
anything involving multiple processes, which always seems like pulling
teeth to me.

For example, his Impossibleness presumably has code which looks like this:

do_a_bunch_of_midi(do, re, mi)
do_something_else(fa, so, la)

All he has to do to get thready with his own bad self is:

import threading
threading.Thread(do_a_bunch_of_midi, (do, re, mi)).start()
do_something_else(fa, so, la)

How hard is that? Going multiprocess involves at least twice as much code,
if not ten times more, will have lower performance, and will make future
changes - like interaction between the two parallel execution streams -
colossally harder.

tom

--
Remember when we said there was no future? Well, this is it.

[Tom Anderson]

On Wed, 16 Nov 2005, sj*******@yahoo.com wrote:

Gorlon the Impossible wrote:

Is it possible to run this function and still be able to do other
things with Python while it is running? Is that what threading is
about?

Threading's a good answer if you really need to share all your memory. A
multiprocess solution is probably preferrable, though it depends on the
architecture.

I'm really curious about this assertion, which both you and Ben Finney
make. Why do you think multiprocessing is preferable to multithreading?

I've done a fair amount of threads programming, although in java rather
than python (and i doubt very much that it's less friendly in python than
java!), and i found it really fairly straightforward. Sure, if you want to
do complicated stuff, it can get complicated, but for this sort of thing,
it should be a doddle. Certainly, it seems to me, *far* easier than doing
anything involving multiple processes, which always seems like pulling
teeth to me.

For example, his Impossibleness presumably has code which looks like this:

do_a_bunch_of_midi(do, re, mi)
do_something_else(fa, so, la)

All he has to do to get thready with his own bad self is:

import threading
threading.Thread(do_a_bunch_of_midi, (do, re, mi)).start()
do_something_else(fa, so, la)

How hard is that? Going multiprocess involves at least twice as much code,
if not ten times more, will have lower performance, and will make future
changes - like interaction between the two parallel execution streams -
colossally harder.

tom

--
Remember when we said there was no future? Well, this is it.

[Gorlon the Impossible]

On Thu, 17 Nov 2005 23:29:16 +0000, Tom Anderson
<tw**@urchin.earth.li> wrote:

On Wed, 16 Nov 2005, sj*******@yahoo.com wrote:

Gorlon the Impossible wrote:

Is it possible to run this function and still be able to do other
things with Python while it is running? Is that what threading is
about?

Threading's a good answer if you really need to share all your memory. A
multiprocess solution is probably preferrable, though it depends on the
architecture.

I'm really curious about this assertion, which both you and Ben Finney
make. Why do you think multiprocessing is preferable to multithreading?

I've done a fair amount of threads programming, although in java rather
than python (and i doubt very much that it's less friendly in python than
java!), and i found it really fairly straightforward. Sure, if you want to
do complicated stuff, it can get complicated, but for this sort of thing,
it should be a doddle. Certainly, it seems to me, *far* easier than doing
anything involving multiple processes, which always seems like pulling
teeth to me.

For example, his Impossibleness presumably has code which looks like this:

do_a_bunch_of_midi(do, re, mi)
do_something_else(fa, so, la)

All he has to do to get thready with his own bad self is:

import threading
threading.Thread(do_a_bunch_of_midi, (do, re, mi)).start()
do_something_else(fa, so, la)

How hard is that? Going multiprocess involves at least twice as much code,
if not ten times more, will have lower performance, and will make future
changes - like interaction between the two parallel execution streams -
colossally harder.

tom

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...

[Gorlon the Impossible]

On Thu, 17 Nov 2005 23:29:16 +0000, Tom Anderson
<tw**@urchin.earth.li> wrote:

On Wed, 16 Nov 2005, sj*******@yahoo.com wrote:

Gorlon the Impossible wrote:

Is it possible to run this function and still be able to do other
things with Python while it is running? Is that what threading is
about?

Threading's a good answer if you really need to share all your memory. A
multiprocess solution is probably preferrable, though it depends on the
architecture.

I'm really curious about this assertion, which both you and Ben Finney
make. Why do you think multiprocessing is preferable to multithreading?

I've done a fair amount of threads programming, although in java rather
than python (and i doubt very much that it's less friendly in python than
java!), and i found it really fairly straightforward. Sure, if you want to
do complicated stuff, it can get complicated, but for this sort of thing,
it should be a doddle. Certainly, it seems to me, *far* easier than doing
anything involving multiple processes, which always seems like pulling
teeth to me.

For example, his Impossibleness presumably has code which looks like this:

do_a_bunch_of_midi(do, re, mi)
do_something_else(fa, so, la)

All he has to do to get thready with his own bad self is:

import threading
threading.Thread(do_a_bunch_of_midi, (do, re, mi)).start()
do_something_else(fa, so, la)

How hard is that? Going multiprocess involves at least twice as much code,
if not ten times more, will have lower performance, and will make future
changes - like interaction between the two parallel execution streams -
colossally harder.

tom

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...

[Scott David Daniels]

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. Processes must be explicit about their sharing (which is where
the bugs occur), so those parts of the code cane be examined carefully.
If you program threads with shared nothing and communication over Queues
you are, in effect, using processes. If all you share is read-only
memory, similarly, you are doing "easy" stuff and can get away with it.
In all other cases you need to know things like "which operations are
indivisible" and "what happens if I read part of this from before an
update and the other after the update completes, .....

That is why threads that don't do trivial things are so scary.

--Scott David Daniels
sc***********@acm.org

[Scott David Daniels]

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. Processes must be explicit about their sharing (which is where
the bugs occur), so those parts of the code cane be examined carefully.
If you program threads with shared nothing and communication over Queues
you are, in effect, using processes. If all you share is read-only
memory, similarly, you are doing "easy" stuff and can get away with it.
In all other cases you need to know things like "which operations are
indivisible" and "what happens if I read part of this from before an
update and the other after the update completes, .....

That is why threads that don't do trivial things are so scary.

--Scott David Daniels
sc***********@acm.org

[Grant Edwards]

On 2005-11-18, Scott David Daniels <sc***********@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.

[...]
That is why threads that don't do trivial things are so scary.

Maybe I've just been using threads too long, but I don't think
they're any more scary than software in general is scary.

--
Grant Edwards grante Yow! I LIKE Aisle 7a.
at
visi.com

[Grant Edwards]

On 2005-11-18, Scott David Daniels <sc***********@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.

[...]
That is why threads that don't do trivial things are so scary.

Maybe I've just been using threads too long, but I don't think
they're any more scary than software in general is scary.

--
Grant Edwards grante Yow! I LIKE Aisle 7a.
at
visi.com

[Donn Cave]

Quoth Grant Edwards <gr****@visi.com>:
| On 2005-11-18, Scott David Daniels <sc***********@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, do**@drizzle.com

(posting this from a Python/BeOS API newsreader)

[Donn Cave]

Quoth Grant Edwards <gr****@visi.com>:
| On 2005-11-18, Scott David Daniels <sc***********@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, do**@drizzle.com

(posting this from a Python/BeOS API newsreader)

[Tom Anderson]

On Thu, 17 Nov 2005, Scott David Daniels 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.
Processes must be explicit about their sharing (which is where the bugs
occur), so those parts of the code cane be examined carefully.

That's a good point.
If you program threads with shared nothing and communication over Queues
you are, in effect, using processes. If all you share is read-only
memory, similarly, you are doing "easy" stuff and can get away with it.
In all other cases you need to know things like "which operations are
indivisible" and "what happens if I read part of this from before an
update and the other after the update completes, .....

Right, but you have exactly the same problem with separate processes -
except that with processes, having that richness of interaction is so
hard, that you'll probably never do it in the first place!

tom

--
science fiction, old TV shows, sports, food, New York City topography,
and golden age hiphop

[Tom Anderson]

On Thu, 17 Nov 2005, Scott David Daniels 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.
Processes must be explicit about their sharing (which is where the bugs
occur), so those parts of the code cane be examined carefully.

That's a good point.
If you program threads with shared nothing and communication over Queues
you are, in effect, using processes. If all you share is read-only
memory, similarly, you are doing "easy" stuff and can get away with it.
In all other cases you need to know things like "which operations are
indivisible" and "what happens if I read part of this from before an
update and the other after the update completes, .....

Right, but you have exactly the same problem with separate processes -
except that with processes, having that richness of interaction is so
hard, that you'll probably never do it in the first place!

tom

--
science fiction, old TV shows, sports, food, New York City topography,
and golden age hiphop