Информация об изменениях

Сообщение Re[40]: Безопасность Rust от 03.06.2019 12:39

Изменено 03.06.2019 12:43 vdimas

Re[40]: Безопасность Rust
Здравствуйте, ·, Вы писали:

V>>Сформулируй свои возражения предметно, плиз, я тогда с ними или соглашусь, или опровергну.

·>Какие возражения?

Свои, ес-но.
От тебя пока прёт пена: "Я не согласен, потому что не согласен".
Пояснить не можешь, так и запишем.
А пролетарское твоё чутьё никому не интересно.


·>Ты заявил "многопоточность в языке появилось давно"


Дословно было сказано:

Это артефакты Си/Linux, где Си разрабатывался для целей написания многопоточной операционки.



·>но своё заявление ничем не подтвердил.


Пока мест это просто исторический факт, который не требуется подтверждать.


·>Так что либо признавайся, что ты насочинял глупостей


Либо я могу признать, что ты не способен обсуждать темы, в которые ввязываешься.


V>>1. Покажи, какие твои цитаты из стандарта я повторяю?

·>

sig_atomic_t это для "asynchronous interrupts made by signals"


Это не цитата из стандарта, это искажение информации, т.е. роспись в неумении читать.
Цитата там такова:

sig_atomic_t — an integer type which can be accessed as an atomic entity even in the presence of asynchronous interrupts made by signals.

Перевод на русский язык требуется?

А тут:

Until C++11, which introduced std::atomic and std::atomic_signal_fence, about the only thing a strictly conforming program could do in a signal handler was to assign a value to a volatile static std::sig_atomic_t variable and promptly return.

?

V>>2. Чем не устроило объяснение модели вытесняющей многопоточности через механизм прерываний? Поясни ошибки в моём изложении.

·>Тем что это объяснение у тебя никто не просил и оно не в тему.

Насчёт "никто не просил" — у тебя забыли поинтересоваться.

Насчёт "не в тему" — пояснить ты не в состоянии, как выяснилось, хотя я уже дважды показывал, почему в тему — из-за самого механизма реализации вытесняющей многопоточности через асинхронный механизм прерываний, который точно такой же, какой в случае использования сигналов.

Одинаковый аппаратный механизм означает одинаковые требования к языку и алгоритмам поверх аппаратуры.
Походу, с понимаем проблемки.


V>>Если алгоритм не требует какой-либо сильной модели памяти, т.е. достаточно модели "relaxed", то достаточно простой атомарности операций чтения/записи переменной.

·>Заблуждение.

Дык, вперёд! Раскрой суть заблуждения!


·>Или ссылки на спеку в студию.


Спеку чего? ))
Какого-нить алгоритма, для которого достаточно relaxed-модели памяти?
Проверка в цикле некоей переменной пойдёт:
static volatile sig_atomic_t flag = 0;

void sig_handler(int signum) {
    if(signum == SIGPIPE)
        flag = 1;
}

...
while(!flag)
    printSomethingToStdout();

?

Через sigaction можно подписаться на более подробную сигнатуру, например, можно узнать, что навернулся именно stdout, а не любой другой pipe.
Re[40]: Безопасность Rust
Здравствуйте, ·, Вы писали:

V>>Сформулируй свои возражения предметно, плиз, я тогда с ними или соглашусь, или опровергну.

·>Какие возражения?

Свои, ес-но.
От тебя пока прёт пена: "Я не согласен, потому что не согласен".
Пояснить не можешь, так и запишем.
А пролетарское твоё чутьё никому не интересно.


·>Ты заявил "многопоточность в языке появилось давно"


Дословно было сказано:

Это артефакты Си/Linux, где Си разрабатывался для целей написания многопоточной операционки.



·>но своё заявление ничем не подтвердил.


Пока мест это просто исторический факт, который не требуется подтверждать.
Разве что вместо Linux (написанного на автомате) надо подставить просто UNIX, конечно.


·>Так что либо признавайся, что ты насочинял глупостей


Либо я могу признать, что ты не способен обсуждать темы, в которые ввязываешься.


V>>1. Покажи, какие твои цитаты из стандарта я повторяю?

·>

sig_atomic_t это для "asynchronous interrupts made by signals"


Это не цитата из стандарта, это искажение информации, т.е. роспись в неумении читать.
Цитата там такова:

sig_atomic_t — an integer type which can be accessed as an atomic entity even in the presence of asynchronous interrupts made by signals.

Перевод на русский язык требуется?

А тут:

Until C++11, which introduced std::atomic and std::atomic_signal_fence, about the only thing a strictly conforming program could do in a signal handler was to assign a value to a volatile static std::sig_atomic_t variable and promptly return.

?

V>>2. Чем не устроило объяснение модели вытесняющей многопоточности через механизм прерываний? Поясни ошибки в моём изложении.

·>Тем что это объяснение у тебя никто не просил и оно не в тему.

Насчёт "никто не просил" — у тебя забыли поинтересоваться.

Насчёт "не в тему" — пояснить ты не в состоянии, как выяснилось, хотя я уже дважды показывал, почему в тему — из-за самого механизма реализации вытесняющей многопоточности через асинхронный механизм прерываний, который точно такой же, какой в случае использования сигналов.

Одинаковый аппаратный механизм означает одинаковые требования к языку и алгоритмам поверх аппаратуры.
Походу, с понимаем проблемки.


V>>Если алгоритм не требует какой-либо сильной модели памяти, т.е. достаточно модели "relaxed", то достаточно простой атомарности операций чтения/записи переменной.

·>Заблуждение.

Дык, вперёд! Раскрой суть заблуждения!


·>Или ссылки на спеку в студию.


Спеку чего? ))
Какого-нить алгоритма, для которого достаточно relaxed-модели памяти?
Проверка в цикле некоей переменной пойдёт:
static volatile sig_atomic_t flag = 0;

void sig_handler(int signum) {
    if(signum == SIGPIPE)
        flag = 1;
}

...
while(!flag)
    printSomethingToStdout();

?

Через sigaction можно подписаться на более подробную сигнатуру, например, можно узнать, что навернулся именно stdout, а не любой другой pipe.