running functions

[Cameron Laird]

In article <11nna381aoiuc57 at corp.supernews.com>,
Grant Edwards  <grante at visi.com> wrote:
>On 2005-11-16, Gorlon the Impossible <meatpodeye at 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/lib/module-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.

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.