On Fri, Apr 14, 2017 at 6:46 PM, Nicolas George <geo...@nsup.org> wrote: > Le quintidi 25 germinal, an CCXXV, Joel Rees a écrit : >> > Summary: Linux has a new system call to allow process to register as >> > adopters for orphan processes. >> Ick. I hope they don't register directly with pid1. > > I am sorry, but that does not even make sense.
Well, this is where the conversation does seem to fall apart. I'm looking at the problem from the point of view of someone who has seen the ins and outs of an engineering principle called complexity. I know enough about complexity to understand that you cannot guarantee response time without properly constraining certain processes -- or, perhaps I should say, supported recurring paths of execution, because you might think I mean a specific entity with a process id on a Unix system, and systemd itself is an example of a unix system process that has multiple actual supported recurring paths of execution. >> Or you could have pid1 monitor only the monitoring process, to keep pid1 >> simple. > > Or you could have PID 1 monitor a process that monitors a process that > monitors a process that monitors a process that monitors the monitoring > process. Talk about strawman arguments. If you care to listen, I am not saying add process redirection to process redirection ad infinitum. There are, of course, limits to what one can do that direction, as well, and caution has to be applied in constructing the redirections. What I'm suggesting does require changes to the kernel. In particular, 16 bits of process id is not enough. How we change that requires some thought, but it is not enough. Systemd already takes a certain approach. Actually, it appears that they are trying two, maybe three approaches. Ultimately it will have to end up being able to resolve the identity of a process at a greater resolution of 1 in 2^16, and distinguish between processes in different ways than just the arbitrary distinction between threads and processes, and the arbitrary distinction between system and user. > Sorry, I do not share your religious imperative of keeping PID 1 simple > at the cost of making everything else more complex. It is easy to call things you don't want to think about "religious". Doing so doesn't solve any problems. If I had time, maybe I could construct a demonstration of the problem of complexity that would make the issues clear. But the demonstrations do exist already. >> pid1 seems to be doing a lot of other things in systemd. Is it >> cooperatively multitasking with itself yet? Or have they borrowed >> threads to define a new kind of process concept, so that pid1 can >> multitask with itself preemptively? >> >> I should go look at the source to see, I suppose > > Obviously you find burning straw men more entertaining. Please go ahead, > I will try not to trouble further. Working out the set of possible execution paths that a critical process can take may look like burning straw men to you, or it may look like wasting time in strawman arguments to you. It appears to look like a waste of time to many people in management. I do hope that what you are saying is that you assume that Poettering and company at least are walking through an informal analysis of the execution paths in systemd. (Formal analysis would be preferred.) Otherwise, your reference in other branches of this conversation to guarantees better than "most of the time" would seem rather, I hate to use the word, but there it is -- duplicitous. -- Joel Rees I'm imagining I'm a novelist: http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html More of my delusions: http://reiisi.blogspot.jp/p/novels-i-am-writing.html