- I'm using a wireless Logitech USB keyboard which acts just like an unreliable datagram service, ie, it loses, reorders or duplicates keystrokes whenever it feels like that (wired version of the same model is no better) -
Didier Kryn <k...@in2p3.fr> writes: > Le 18/02/2016 18:05, Steve Litt a écrit : [...] > I probably mixed with the explanations of Laurent in his > motivations for s6 (http://skarnet.org/software/s6/why.html). I quote > the paragraph under the title "Supervision suites should be bug-free, > lightweight and easy to understand.": > > <<System V init is understandable, and reasonably lightweight; but it > is still too big for what it does - poorly. The /etc/inittab file > needs to be parsed; that parser has to be in process 1...>> But the /etc/inittab syntax is fairly simple. This means the complete parser (just the parser, not the code "executing" "the parse-tree") is /* try to fopen /etc/inittab as fp */ while(!done) { /* * Add single user shell entry at the end. */ if (fp == NULL || fgets(buf, sizeof(buf), fp) == NULL) { done = 1; /* some 'execution' code here */ continue; } lineNo++; /* * Skip comments and empty lines */ for(p = buf; *p == ' ' || *p == '\t'; p++) ; if (*p == '#' || *p == '\n') continue; /* * Decode the fields */ id = strsep(&p, ":"); rlevel = strsep(&p, ":"); action = strsep(&p, ":"); process = strsep(&p, "\n"); } NB: The rlevel and process fields additionally need to be 'parsed'. I wouldn't write it myself in this way and I also think this leaves something to be desired from a structual point of view, ie the way the loop is terminated is messy, but it's certainly no terribly complicated piece of arcane code (to someone who's proficient in C). [...] > The scheme proposed by Laurent is that pid1 supervises the > supervisor. There's obviously a "Quis custodiet ipsos custodes?" problem here but the (IMHO) sensible way to deal with it is to accept that not all conceivable failures can be guarded against instead of "create a cascade of processes doing nothing watching over processes also doing nothing": 'Real' servers tend to fail for unforeseen reasons because they're complicated. So, use a simple program restarting the complicated ones if they suddenly terminate and be happy that only bugs in the simple program will have lasting consequences. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
