Вопрос по man fcntl, что бы оно значило...

Шо ж тут непонятного ... если некий процесс не проверяет локи, то ему ничто не мешает читать/писать.

Соответственно, процессы являются cooperative если согласованно ставят/анализируют локи.

Тогда чем отличается Advisory locking от Mandatory locking?

Процессы в обоих случаях могут блокировать файлы.

Мне не понятно, что это за свойство кооперативности у процессов. То что они могут блокировать файлы это понятно. Но я упор не вижу разницы в функционировании Advisory locking и Mandatory locking.

Mandatory locking отличается от Advisory locking только:

Advisory locks are not enforced and are useful only between cooperating processes.

Ну ещё отличие:

If the O_NONBLOCK flag is not enabled, then system call is blocked...

> Тогда чем отличается Advisory locking от Mandatory locking?

При Mandatory locking блокировки накладываются/анализируются еще и функциями read/write. Это означает, что если одно приложение получило монопольный доступ к некоторому куску файла с помощью fcntl, то второе приложение этот кусок не сможет прочесть, даже если ни о каких явных блокировках оно не заботится вообще.

Я думаю, что ответы на такие вопросы лучше искать в какой-нибудь википедии, чем в мануале по libc.

> Я думаю, что ответы на такие вопросы лучше искать в какой-нибудь википедии, чем в мануале по libc.

А еще лучше - в стандартах типа POSIX или SUS

Всем спасибо, буду рыть.

Тут выяснилась такая штука. Когда я тестировал sys_waitpid с флагами WUNTRACED и WCONTINUED всё было красиво. Дитё останавливалось по сигналу и стартовала по сигналу, sys_waitpid возращал корректное значение pid по каждому из флагов. Но когда дитё стопорнулось на write, получилось, что sys_waitpid не реагирует на изменение состояния детёныша, а реаг\ирует только когда детёныш завершается.

Это я торможу или waitpid с флагами WUNTRACED, WCONTINUED обнаруживает изменение состояние только, когда детёнышу посылают SIGSTOP и SIGCONT соответсвенно?

должен ли waitpid реагировать на изменение состояние детёныша, если он блокируется на write?

Имеется ввиду, что write блокируется на файле, который соответсвенно блокируется/разблокируется по fcntl другим процессом.

Я ожидаю, что при если write блокируется на файле, заблокированном н другим процессом fcntl-ем, то waitpid должен возращать изменение состояние детёныша, так же как и по разблокировке файла fcntl-ем, waitpid должен возращать изменение состояния. Пока этого нет.

> Я ожидаю, что при если write блокируется на файле, заблокированном
> н другим процессом fcntl-ем, то waitpid должен возращать изменение
> состояние детёныша, так же как и по разблокировке файла fcntl-ем,
> waitpid должен возращать изменение состояния. Пока этого нет.
>

Куча заблуждений и полное непонимание в одной фразе :-(

1. waitpid() сработает если процесс завершился или (если просили
WUNTRACED) процесс остановлен, то есть получил сигнал SIGTTIN,
SIGTTOU, SIGTSTP, или SIGSTOP. Если же процесс заблокирован (не
путать с "остановлен"!) в каком-то системном вызове (например write)
то это не имеет _никакого_ отношения к waitpid().

2. Advisory блокировка fcntl() _никак_ не влияет на возможность
доступа других процессов к файлу. Другие процессы должны (если
хотят "кооперации") также использовать fcntl() для установки/снятия
блокировок перед тем, как делать свои read/write/что-то-еще.

Короче, Стивенса почитай, что-ли...