On Mon, Oct 13, 2014 at 10:47 PM, Miles Fidelman <mfidel...@meetinghouse.net> wrote: > Chris Bannister wrote: >> >> On Mon, Oct 13, 2014 at 07:14:29PM +0900, Joel Rees wrote: >>> >>> On Mon, Oct 13, 2014 at 4:18 PM, Jonathan Dowland <j...@debian.org> >>> wrote: >>>> >>>> On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote: >>>>> >>>>> On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read <zen75...@zen.co.uk> >>>>> wrote: >>>>>> >>>>>> On 12/10/14 18:13, John Hasler wrote: >>>>>>> >>>>>>> You have no problem with an 1800 line function? >>>> >>>> ... >>>>>> >>>>>> I have a problem with 1800 line functions in general; >>>> >>>> ... >>>>> >>>>> I have no problem with an 1800 line function. >>>> >>>> ... >>>> >>>> *What* 1800 line function? The commit URI that was shared was an >>>> 1894-line >>>> *file* with a large function definition starting at line 638 and ending >>>> at >>>> 1890. That's a 1252-line function. >>> >>> mmm? 1800 vs. 1252 ? >>> >>> 30 years ago, when we still read printouts, 60 lines was considered >>> the ideal max because that's what would fit on a page. >>> >>> Nowadays, we use a screen, but 60 lines is hard on the eyes (9 pt or >>> so), so 40 lines is a good screen-full. But it turns out, with being >>> about to scroll quickly, that 60 lines is still not hard to reach. >>> Moreover, 60 lines seems to be a pretty good average for what an >>> experienced coder can keep in his head. >> >> LOC is a silly way to measure anyway. You could put all the code on one >> line --- PITA to read, but hey! it's only one line of code! :) >> > > Go Perl. > Go APL. > :-)
I'm afraid the reasons we don't use perl or APL to write pid 1 code is not clear to most casual readers, so I'll be uncool and say it out loud: Non-deterministic execution. If pid 1 gets stalled, lots of things all over the system get to wait for something important that can't happen until pid 1 gets un-stalled, and that's true even with quad core. It may not freeze every process, but it can cause dropped packets and such things. Potentially, you could, every now and then, lose a buffer-full of data headed for a file on disk, as well. Again, to be painfully pedantic, one in ten thousand buffers is more of a problem than one in a hundred. You notice frequent dropped buffers, so you're likely to fix the problem. Infrequent dropped buffers tend to be not noticed until the data is lost. The only way to fix that in systemd is for systemd to delegate the complicated stuff like managing dbus to child processes, so the processes that will occasionally stall won't impact the whole system as much. When/if that happens, we should see the hard dependencies between systemd and other stuff that has been absorbed by systemd disappear. The real problem is that Poettering and others over there have rather indicated an unwillingness to do that. If we are willing to accept this kind of engineering, we have to assume that either the developers at systemd will eventually get around to a proper refactoring of the processes (and not just code within pid 1), or we have to hope that open processes will ultimately force their hand. -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43imlfvvy0+pm+eejr_xjwuzh8mtvedsgqt87_d6ujth...@mail.gmail.com
