Didier Kryn <kryn@???> writes:
> 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.

[...]

>     I agree with you, and it was the first point in my mail, that the
> servers should be able to cope with outages.

That's not a matter of "should": They have to. Even if it's believed
they're just using local IPC[*].

> However let's not be extremists.

Feel free to consider yourself 'an extremist', ie, someone fighting
(often violently) for a certain policy regardless of reason but please
don't label me in this way: The issue is technical and not political and
the proposed solution doesn't work.

> In most cases this is going to work, because
> Time_of_check_to_time_of_use issues do not arise all the time.

That's a property of any problem caused by a race condition: The time
when the latent problem will manifest itself can't (easily) be
predicted.

[*] Or so. Assuming we're not dealing with UNIX(*) but a much more
primitive system where

    - servers only utilize file-descriptor based IPC

        - all names of IPC objects are known in advance

        - the set of servers is static and known at boot time

    - the filesystem namespace can't be reconfigured at run time

        - no other 'static' system configuration information can change
          at run time

    - there are no real-time requirements

        - servers are completely stateless (this includes that they
          aren't using 'virtual circuits' for I/O)

        - there's no network

        - it's OK for the system to deadlock completely because all
          threads either directly or indirectly block waiting for an
          event which will never happen

          [probably not exhaustive]

and additionally assuming that the socket management code is guaranteed
to be free of errors, then, the issue can be 'solved' with systemd-style
'socket activation'.
?
Now, since this computer system surely exists somewhere behind the
mirror but not anywhere else, can we sell it nevertheless? And while
we're at it, can we also get by with renaming / to something sensible
and intuitive like C:?