From: Guillaume L. <gla...@te...> - 2002-08-20 22:11:40
|
On Tuesday 20 August 2002 20:52, Chris Cannam wrote: > -- It would be practically complicated to manage a fixed- > width file format when the sorts of data we send are > relatively varied It's not, in the end it's just MappedEvents (e.g. about 10 ints and a string). > and the business of (for example) > locating a start point for reading mapped events from > the file into the sequencer, when the file could change > at any time, could be error-prone. In other words, I > don't believe it's all that much simpler than threading. No, the format of the file should be something like this 1...423..789... 12..32...723... 4.,.799..34.... 7...43...899... 3...2....3..... (use a fixed font). Therefore any change can't disrupt the reading. Plus the file won't change without the sequencer knowing it because you need to call msync() for that. > -- It'd introduce yet another new event format A trivial one, which will actually replace MappedEvent, and we'll probably won't need MappedComposition anymore. > and another > new communications paradigm quite different from any that > we currently use. The threading approach would leave > these things almost exactly as they are. But it won't solve the core problem which is the overhead of fetching event data, serializing it, passing it through DCOP, deserializing it and then play it. Here it will be a trivial parse. > -- It might reduce our flexibility to drive other sorts of > things from the same core, whereas a threading model > might increase flexibility and possibly also simplify > the design: for example, it might end up being > advantageous to move the sequencer into the same thread > as the getSequencerSlice() code rather than run it as a > separate process, who knows. We should be able to change > our minds relatively easily about things like that. There are at least two reasons why I don't think we'll ever want the sequencer to be in-process : - reliability : in case of buggy drivers, whatever, it's better to have the sequencer crash on its own and the GUI still be able to save its data. - security : having the sequencer as a seperate process allows us to get it to run with real time priority if needed, which means running it as suid root, which implies being pretty sure about its security. It would be much easier to audit the sequencer than the whole GUI for potential exploits. > I guess these pretty much add up to: threading has one thing > to get right (a sensible locking design), and should then > bring various practical benefits without any radical changes > to any of the existing code. But I precisely think that the code *needs* radical changes, i.e. reducing the overhead between the GUI and the sequencer. > Your alternative would change > pretty much all of the existing comms model between the > sequencer and GUI. Yes, but it would simplify it a great deal. > If they bring similar benefits, then I > think we should at least attempt to do threading unless we > find there are real problems with it that make it untenable. > > I don't think we should do either of them now, although I'm > tempted to knock out some test cases for threads and locks in > the base/test directory. And I'm tempted to at least prove my concept. I'll try to do that in the coming few days, probably in a seperate branch. -- Guillaume. http://www.telegraph-road.org |