On Sep 13, 2012, at 10:54 AM, Fred Gleason <[email protected]> wrote:
> 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). While I won't argue that they are services, the question becomes is the value added by making the services live in separate processes. I grew up on Unix back in the mid 1980's when machines were so slow, that spending 2-3 hours compiling something that builds in 5 minutes now, seemed "fast" at the time. Small self contained programs do have their power, and especially when there was so much text mode processing, and pipes on the shell command line could provide a great mechanism for wiring up completely new applications, without "programming". Where I'm trying to draw the line, is where the separation of responsibility actually creates more problems because of management of the whole package. It is nice to have small bits of responsibility done "right". > >> 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. But, the Apache web server model uses a parent process to watch over the sub processes that do the work. That works well, and can be quite well managed. The disconnect I am pointing out, is the fact that there are processes running in the background which are not "managed" by a central process (well init I suppose), that is "the application". > >> The lifecycle is disconnected from apps which don't have a common parent >> process. > > Not an issue if IPC is implemented properly. There are some forms of IPC which allow lifecycle tracking (pipes). Other forms (sys-v shared memory, semaphores and messaging) do not make it obvious what is happening with the other processes. Pipes work well for sub process relationships, except for kernel buffering. Sockets provide a better indication of the other ends existence. > >> 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. Okay, that sounds like a great change in process management, and is what I was trying to point toward. > > >> 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'. Posix threads can be a pain for sure. Moving to a single process with sub-processes as you mention above is at least a more readily managed process structure that can help eliminate the issues regarding lifecycle and UID management. I understand that there is a lot of code behind rivendell. I'm excited that there is work going on to try and address the issues that make using rivendell more difficult when starting up a new machine. Thanks Fred! Gregg Wonderly _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
