С вашего позволения тезисно перескажу пост, чтобы более чётко артикулировать свою точку зрения.
Согласно POSIX, функция lockf должна возвращать ошибку, когда система замечает дедлок.
Linux реализует такой детектор дедлоков. И в документации, и в коде написано, что он может давать как false positive-ы, так и false negative-ы.
Я обнаружил случай, строго говоря, ещё одного false positive-а со стороны детектора дедлоков, не упомянутый в документации. Он касался распространённого сценария использования потоков в коде.
Я пожаловался на этот случай мейнтейнерам соответствующего кода.
У меня возникла смелая мысль, что раз детектор обладает такими интересными свойствами, то было бы хорошо по крайней мере поправить man, чтобы сказать: он плохо дружит с тредами.
На правку POSIX не претендую. Он здесь вообще почти не при делах.
Возможно, я плохо искал, но где можно найти информацию о том, куда/кому жаловаться на баги и где/кому задавать вопросы? Или это передаётся из уст в уста, как сейчас? Или нужно логическим путём понять, что жалоба на баг или вопрос -- это как недопатч, и потому если с патчами надо обращаться так-то, то и с репортами/вопросами нужно обращаться аналогично?
Из описания в MAINTAINERS следует:
Descriptions of section entries and preferred order
... B: URI for where to file bugs. A web-page with detailed bug filing info, a direct bug tracker link, or a mailto: URI. C: URI for chat protocol, server and channel where developers usually hang out, for example irc://server/channel.
Но в секции "FILE LOCKING (flock() and fcntl()/lockf())" нет ни B:, ни C:.
Что мне кажется нехорошим в сигналах, так это как они работают по умолчанию. Если какие-то сигналы приложению не нужны, оно должно явно сказать об этом. Если не скажет, то оно будет обрабатывать их не самым очевидным образом. Мне кажется, почти все сигналы по умолчанию было бы очевиднее всего игнорировать, а не падать в корку.
Я не считаю, что передача информации по SMS более надёжна, чем https.
Мой point был такой. Предположим, что злоумышленник получил доступ к аккаунту жертвы на сайте, но не имеет её второго фактора аутентификации — мобильного телефона, потому не может просто переслать себе деньги. Он решает оплатить что-то с помощью карты. Для этой задачи раньше ему нужно было подобрать больше десятичных цифр, чем после изменений в алгоритме. (Особенно с учётом того, что последние цифры являются полупубличной информацией, так что в теории их можно где-то найти.) Комбинаторная сложность в конкретном сценарии уменьшилась.
Отличная идея! Благодарю, переделал. Кажется, стало намного лучше.
С вашего позволения тезисно перескажу пост, чтобы более чётко артикулировать свою точку зрения.
Согласно POSIX, функция lockf должна возвращать ошибку, когда система замечает дедлок.
Linux реализует такой детектор дедлоков. И в документации, и в коде написано, что он может давать как false positive-ы, так и false negative-ы.
Я обнаружил случай, строго говоря, ещё одного false positive-а со стороны детектора дедлоков, не упомянутый в документации. Он касался распространённого сценария использования потоков в коде.
Я пожаловался на этот случай мейнтейнерам соответствующего кода.
У меня возникла смелая мысль, что раз детектор обладает такими интересными свойствами, то было бы хорошо по крайней мере поправить man, чтобы сказать: он плохо дружит с тредами.
На правку POSIX не претендую. Он здесь вообще почти не при делах.
Надеюсь, я ответил на ваш вопрос.
Спасибо за пояснение!
Возможно, я плохо искал, но где можно найти информацию о том, куда/кому жаловаться на баги и где/кому задавать вопросы? Или это передаётся из уст в уста, как сейчас? Или нужно логическим путём понять, что жалоба на баг или вопрос -- это как недопатч, и потому если с патчами надо обращаться так-то, то и с репортами/вопросами нужно обращаться аналогично?
Из описания в MAINTAINERS следует:
Но в секции "FILE LOCKING (flock() and fcntl()/lockf())" нет ни B:, ни C:.
Мой point был такой. Предположим, что злоумышленник получил доступ к аккаунту жертвы на сайте, но не имеет её второго фактора аутентификации — мобильного телефона, потому не может просто переслать себе деньги. Он решает оплатить что-то с помощью карты. Для этой задачи раньше ему нужно было подобрать больше десятичных цифр, чем после изменений в алгоритме. (Особенно с учётом того, что последние цифры являются полупубличной информацией, так что в теории их можно где-то найти.) Комбинаторная сложность в конкретном сценарии уменьшилась.