Rob Fell wrote: > Peter Brinkmann wrote: > >>> Would this work for you? > > > Almost. I see no need (in my application) to ensure that the GUI > > events are serialised at the correct time in the event stream. > > > > I favour a periodic callback since a timeout on poll() indicates that > > there are no events pending - hence it would be a reasonable time to > > handle GUI events. > > That's essentially what midiplayer.py does. Since most MIDI files > contain a lot more events than can be scheduled at once, midiplayer.py > just schedules a batch of a few hundred events at a time, followed by > an echo event addressed to itself. Then it just sits around waiting > for this echo event to arrive, at which time it schedules the next > batch as well as another echo event, etc. > > In your situation, you may just want to set things up in such a way that > the MIDI thread keeps sending itself echo events at regular intervals. IIUC in the case of midiplayer.py, all the events are generated by software: in my case I'm trying to merge a live stream from a physical device with events generated either by other physical devices or via the GUI. GUI interaction should stall whilst there are real events to process - and the easiest way I see to handle this is to use the poll() timeout. I can try other means of thread synchronisation, but I fear that will massively complicate the locking :( R
