Nil A написал(а) к Alexey Khromov в Jun 23 02:12:20 по местному времени:

Нello, Alexey!

Friday June 02 2023 21:10, from Alexey Khromov -> Nil A:

NA>> Взаимозависимость - это когда возможна ситуация дедлока? Вроде бы
NA>> никому из них нет необходимости держа один лок, при этом ещё
NA>> хватать другой.
AK> Это прописывание изменений в нескольких независимых проектах, с
AK> возможной в итоге несовместимостью с альтернативами.

Для этого есть стандарты, и ещё эти комитеты, где чуваки собираются побухать. Только FTSC комитет давно уже потерял легитимность, тогда как IETF продолжал встречаться и даже в ковид/подстковид и принимать решения. Даже, умерший C++ прям фонтанирует после c++11, 14, 17, 20, 23, 26.. Почему C++ тоже умер? Шутка, он не умер, но многие говорил, что вот язык [...] это c++ киллер.

NA>> Флаги - это всё костыли.
AK> Флаги - один из способов IPC (Inter-Process Communication,
AK> межпроцессное взаимодействие). Кстати, наиболее универсальный,
AK> работает от DOS и до наших дней.

Тебе простой вопрос, как ты будешь старые флаг-файлы чистить? Ну понятно, что если забутился только, то можно их всех стереть, а так если? Pid внутрь класть, и проверять, если в системе такого процесса больше нет, то флаг-файл устарел. Или флаг файл ты будешь лочить, и тогда, если процесс помёр, и файл не удалил, то ОС освободит лок? Это я к тому, что флаги, в качестве IPC - это тот ещё геморой.

NA>> потому что договорились о блокировке файла
NA>> средствами ОС.
AK> Где договорились?

Вот, какой-то JAM-001.TXT есть, ниразу ни FTSC, ну просто они не можут ничего, кроме нового fta-1003 выпустить.

==Begin===
=====================================================================
Message base sharing and locking
---------------------------------------------------------------------
To allow several programs to access the message base at any given
time, region locking is used to protect the message base from being
corrupted during updates.

When an application needs to write to any of the message base files,
it must first attempt to lock the first byte of the .JНR (header)
file. If the lock call fails, the application must either fail or
attempt to lock the file again. The message base files may under no
circumstances be updated if the application cannot successfully lock
the .JНR file.

Note that data acquired (read) from the message base may not be used
when writing data to the message base, unless the application has
maintained a lock of the message base from the time the data was
acquired or the MODCOUNTER field is the same as when the data was
acquired.

The application must open the files in shareable (DENYNONE) read/
write or readonly mode. The only exception to this is an application
that requires exclusive access to the message base, such as a message
base maintenance utility, it should open the files in non-shareable
(DENYALL) read/write mode.
===End===

А вот ещё, FSP-1037, про Squish, тоже не случился, по известной причине

===Begin===
The "Update" frame type is not needed in modern software because
file locking feature is more convenient to prevent access to the
frame, but software SНOULD check and set frame type to "Update" when
works with this frame.
==End===

Best Regards, Nil
--- GoldED+/LNX 1.1.5