Threads vs subprocesses

[John O'Hagan]

On Fri, 15 Jun 2012 16:34:57 -0400
Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:

> On Sat, 16 Jun 2012 03:24:13 +1000, John O'Hagan
> <research at johnohagan.com> declaimed the following in
> gmane.comp.python.general:
> 
> 
> > I should have made it clear that I'm not using threads to speed anything up;
> > each thread produces an independently controlled, timed stream of musical
> > events. I think it would be hard to achieve that in a single process. The
> > streams need to run simultaneously without getting out of sync or dropping
> > notes, which begins to happen if there are a lot of them, or they are run
> > very fast or are very calculation-intensive to produce. 
> >
> 	Sounds like something in the realm of discrete event simulation...
> which is commonly single-threaded -- a list of events & time-points
> which dispatch to event handlers as time is incremented...
> 
> 	Or for your case: a time-ordered list of stream&event; issue all
> events at a given time point, then dispatch to each stream to compute
> the next event&time for that stream, which is placed into the ordered
> list. Read the first pending event, sleep until the event time is
> reached, then repeat the process.


That looks like a possible way to do all the streams in a single thread,
although it works a little differently from your outline above if I understand
you correctly, in that only the events know their start times and they are
produced by iterators which can be modified on the fly and which can be added
and removed from the overall process at any time, so it's not possible to know
in advance which iterator will produce the chronologically next event. I think
that means that any ordered list of events would have to be re-ordered after
each event is read. It might be worth a try though. I notice there is simpy for
discrete event simulation in python. I'll look into it, thanks.

John