Re: If Linux Is About Choice, Why Then ...
On Fri, Apr 14, 2017 at 6:46 PM, Nicolas George <george@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
Reply to: