Да это понятно, просто предыдущий оратор, наверное, имел ввиду, что проблема, для решения которой якобы был издан такой сертификат, решается другим способом. А по факту мы имеем дело просто с отмазой.
Да это всё понятно, я просто к тому, что данная новость воспринята как-то легко. Ну нашли левый сертификат, выданный на гугл, ну нашли того, кто в этом виноват, ну уберут из доверенных этот trusted root только в следующей версии.
А то, что, наверняка, кроме гугла ещё куча таких сертификатов есть — это как-то не обсуждается. Камент был про то, что надо взгянуть на проблему шире, а успокаиваться рано.
вообще-то браузер проверяет, что сертификат выдан тому домену, на который ты зашел. однако на один и тот же домен сертификат может быть выдан кучей разных CA, и понять какой из них левый, без отпечатка ключа нельзя.
А на гугле свет клином сошелся? Почему эта контора не могла сгенерить поддельные сертификаты на еще кучу компаний, публичные ключи которых не вшиты в браузеры?
При всей силе аргументов, которые приводит уважаемый amosk то, что он пытается приподать под соусом thread safe, является на самом деле async signal safe. С этой точки зрения memcpy не является async signal safe функций, а все сокетные операции — являются. При этом и те, и другие являются thread safe.
То, что мы обсуждаем, это именно то, что гарантирует async signal safe. memcpy не является async signal safe функцией именно по пункту 2. A все операции с файловыми дескрипторами — являются.
Описанный автором поста случай ничем не отличается от случая, когда мы имеем однопотоковое приложение, которое делает в основном потоке close, в этот момент случается какой-то сигнал и в нём оно делает read или write на данном дескрипторе. Этот же race condition (если он существует), приведет к такому же подвисанию, а значит это — bug.
Ваш пример подверждает только ваш пример, ввиду фундаментальности ограничений с данной опеацией. Вы же пытаетесь распространить это на весь стандарт POSIX. Это нелогично и незаконно.
Согласитесь, что если бы это было так, то сокет был бы сделан без упомянутого вами мутекса, так как синхронизация доступа к сокета — это был бы гемор программиста.
Кроме того, если вы беретесь говорить за весь POSIX, то не сочтите за труд сюда ссылку или цитату в качестве пруфа.
Касательно ядренного мутекса. Допустим, что он там есть. Каким образом, он может спровоцировать описываемое поведение да ещё так, чтобы оно считалось корректным с т.з. стандарта?
Если вы говорите, что там race condition, то мьюеткс как бы должен как раз помогать избегать race condition.
Если мы говорим о зависании, то это уже dead lock, но для возможности dead lock необходимо наличие нескольких мутексов.
Подождет пока к нему придут данные. Вместе с ним подождет и прерванный поток. Большого смысле в этом, наверное, нет, но если они таки придут, то ничего страшного не случится. Так, например, write в обработчиках используется и в хвост, и в гриву. А вы в своём каменте обощили до всех операций над сокетом, а теперь пытаетесь доказать, что смысла в таком использовании каких-то конкретных функций нет.
Ниже вашего камента, коллега ошибочно показал на список согласно стандарта thread safe functions, который на самом деле является списком non thread safe functions. Так вот ни read, ни close, ни какой-либо другой функции там нет.
Мне кажется, вы не прочитали то, что предшествует непосредственно этому списку функций:
POSIX.1-2001 and POSIX.1-2008 require that all functions specified in the standard shall be thread-safe, except for the following functions
То, что вы говорите, это в высшей степени возмутительно! Ибо опреации на сокетах, как и другие системные вызовы, являются функциями класса async signal safe [1], то есть разрешенными к использованию в обработчиках сигналов. Рассказывать, почему функция, которая использует мьютекс не может являться async signal safe?
Это да и фактически надо делать exec после этого, иначе состояния объектов синхронизации, которые клонировались после форка, в непредсказуемом состоянии. Но если ты никогда этим вопросом не заморачивался, то вопросов будет много.
У вызова clone есть куча флагов, которые указывают то, что клонировать, а что нет. Мне кажется, что при вызове pthread_create в clone не передаётся флаг CLONE_FILES, а вот при вызове fork — передается.
Если вы хотите ещё прекрасных загадок, которые вам сломают голову, то можно, например, погрузиться в то, что происходит, когда многопоточному приложению делают fork() :-)
А то, что, наверняка, кроме гугла ещё куча таких сертификатов есть — это как-то не обсуждается. Камент был про то, что надо взгянуть на проблему шире, а успокаиваться рано.
Описанный автором поста случай ничем не отличается от случая, когда мы имеем однопотоковое приложение, которое делает в основном потоке close, в этот момент случается какой-то сигнал и в нём оно делает read или write на данном дескрипторе. Этот же race condition (если он существует), приведет к такому же подвисанию, а значит это — bug.
Кроме того, если вы беретесь говорить за весь POSIX, то не сочтите за труд сюда ссылку или цитату в качестве пруфа.
Если вы говорите, что там race condition, то мьюеткс как бы должен как раз помогать избегать race condition.
Если мы говорим о зависании, то это уже dead lock, но для возможности dead lock необходимо наличие нескольких мутексов.
Ниже вашего камента, коллега ошибочно показал на список согласно стандарта thread safe functions, который на самом деле является списком non thread safe functions. Так вот ни read, ни close, ни какой-либо другой функции там нет.
POSIX.1-2001 and POSIX.1-2008 require that all functions specified in the standard shall be thread-safe, except for the following functions
[1] man 7 signal
Если вы хотите ещё прекрасных загадок, которые вам сломают голову, то можно, например, погрузиться в то, что происходит, когда многопоточному приложению делают fork() :-)