On Fri, 15 Jun 2012 16:34:57 -0400 Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
> On Sat, 16 Jun 2012 03:24:13 +1000, John O'Hagan > <resea...@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 -- http://mail.python.org/mailman/listinfo/python-list
