Steve Litt <slitt@???> writes:
> On Tue, 03 Nov 2015 16:18:07 +0100
> Didier Kryn <kryn@???> wrote:
>> Le 02/11/2015 15:53, Rainer Weikusat a écrit :
>> > Didier Kryn <kryn@???> writes:
>> >
>> > [...]
>> >

>> >>      Reporting readyness is admin-friendly, but this can be done
>> >> trivially, in the s6 fashion; it does not take a library to do.
>> > https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use
>> > https://cwe.mitre.org/data/definitions/367.html
>> > https://isecpartners.github.io/news/research/2015/03/03/recognizing_preventing_toctou.html

>> >
>> > [and no end of other links]
>> >
>> > The problem can't be solved other than by processes which need to
>> > talk to other processes implementing a strategy for coping with
>> > transient outages.

[...]

>> In most cases this is going to work, because
>> Time_of_check_to_time_of_use issues do not arise all the time. In
>> this last case, signalling readyness is easily done by writing a
>> newline to standard output - no need for a library.
>
> There's an init system called s6-rc

[...]

> and I think it has an extremely simple way for processes to
> communicate readiness.

That was what Didier was also writing about already. But it doesn't
matter how simple (or complicated) an attempt to build the perpetuum
mobile ends up, it's still condemmed to fail. The problem cannot be
solved in this way because the system is dynamic: Its state changes over
time. This means that either processes in need of services provided by
other processes can cope (somehow) with these services not being
available, then, this whole, extremely complicated machinery is simply
not needed, or they can't. Then, it's also not needed because it doesn't
help.