Сейчас WINE@Etersoft не использует F_GETLK при работе с NFS. Надо сделать, чтобы F_GETLK не использовался и при работе с CIFS, так как он довольно медленно работает.
Посмотрел, где используется F_GETLK. В закрытой части: в set_concurlock (проверка числа пользователей, работающих с одним файлом, лицензионное ограничение), в getc_lock. Эти функции используются при открытии файла. В открытой части: в set_unix_lock (установка блокировки), при работе с файлом /tmp/.wine-*/server-*/lock (думаю, это нам не интересно). 2 piastry@: что нам нужно оптимизировать: установку блокировки с помощью LockFile или открытие файла?
Любое использование GET_LK при работе через CIFS порождает два запроса на сервер, потому от него надо уходить везде, где это возможно - то есть и при открытии, и при установке блокировки.
Функция getc_lock проверяет наличие блокировки либо с помощью двух F_SETLK, либо с помощью F_GETLK. Так что с ней, видимо, ничего не сделаешь.
Заметил, что в случае с NFS функция set_concurlock вызывается 2 раза для одного и того же файла. Переделал.
Ещё одно изменение, касающееся на самом деле NFS, а не CIFS. Перенёс вызов release_lock в etersoft_sharing_post, где устанавливаются новые блокировки, ответственные за режим открытия файла. До этого мы могли сбросить блокировки, а новые не поставить (в случае выхода из check_sharing до вызова etersoft_sharing_post). Также сделал, чтобы release_lock использовала специально открытый для установки блокировок дескриптор.
Сделал, чтобы в set_concurlock не использовалось F_GETLK (http://bugs.etersoft.ru/show_bug.cgi?id=6441).
В set_unix_lock есть два места, в которых используется F_GETLK. В одно из них мы на CIFS не попадаем. В другое мы попадаем в случае файла, открытого только на чтение.
Мне кажется, что установка блокировки на файл, открытый только на чтение - не очень частая ситуация. Она возникает в 1С7.7 при входе в некоторые базы (бутылка 1c77/1c77-scaner, конфигурация "Торговля+Склад") и при обновлении в мониторе пользователей. А для того, чтобы избежать использования F_GETLK в данном случае, придётся открывать дополнительный дескриптор, что не очень хорошо. Думаю, не стоит ничего делать с set_unix_lock, пока не выяснится, что это действительно узкое место.
Принято.
