On Sep 13, 2012, at 10:22 18, Gregg Wonderly wrote: > The practical issue, from my perspective, is that there are "server" > processes running in the background which are managed by the "service" > interface. Practically, I really think that a better choice would be to run > and manage those processes from the foreground. If the "GUI" is really the > control point of the platform, then a foreground process should really manage > everything about the runtime environment for the play out machine.
It uses the service interface because that's exactly what it provides: system services --e.g. RML processing, RDCatch events, etc. Those need to happen on a Rivendell system independent of any given GUI component; indeed, even when *no* GUI components are active. This is the Un*x philosophy in action; small, self contained programs with well defined IPC interfaces that each do one thing well, rather than huge monster monoliths that try to do everything (and all too often break catastrophically when a fault in one thread cascades through the rest of the stack). > It's really hard to manage "multiple" processes reliably. I disagree. Un*x systems have been doing this quite reliably since the 1970s; it's been the default services model since Ken Thompson laid down the first line of code at Bell Labs. The Apache web server (among many, many others) uses this model; at last count, that application runs well over 50% of all web servers on the planet. > The lifecycle is disconnected from apps which don't have a common parent > process. Not an issue if IPC is implemented properly. > The runtime "user-id" becomes an issue that is also visibly frustrating to > deal with. I agree with you on this one. Running the RD daemons as UID 0 (as we do in both 1.x and 2.x) is plain evil, not to mention the fact that it hugely complicates JACK setups (where all the clients need to run under the same UID). This wart has been fixed in RD 3.x, where the daemons run as 'user agents' (a phrase borrowed from OS X): background processes that run under the same UID as the user login session and whose lifetimes are concurrent with that session. > When "multi-threading", was not generally available, multi-programming was > the paradigm of choice. But now that multi-core is everywhere, and > multi-threading is available, it seems like it might be time to reconsider > embedding the services into a single, foreground app so that the user > experience is "consistently" the same. Again, I'm afraid I have to disagree. While this may be true on platforms that offer only weak IPC and process control models (a certain one made by a company in Redmond Washington comes to mind), my own experience on Un*x-ish platforms has been exactly the opposite. The POSIX threads specification is a spagetti bowl of ambiguity; key areas (like signal handling) are so weakly defined that there are now different 'complaint' implementations that operate in totally different ways. Even aside from that, jamming everything into a single process space is asking for trouble in a large application suite. See the point above about 'monster monoliths'. Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-------------------------------------------------------------------------| | Threads -- Threat or Menace? | | | | -- chapter heading from | | "The Art of UNIX Programming" | | by Eric Raymond | |-------------------------------------------------------------------------| _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
