Плохо документированные особенности Linux

del

Плохо документированные особенности Linux

А пруф где?

Пруф я уже приводил:

    std::thread t1{[=]{ reader(s[0]); }};
    t1.join();
    std::thread t2{[=]{ reader(s[0]); }};
    t2.join();

Если бы сокет был склонирован, то данный код подвисал бы на втором read().

Плохо документированные особенности Linux

Да не клонируются сокеты/файлы для потоков.
Это один сокет. А то что вы наблюдаете — обычный race condition.
Вообще насколько я помню нигде не гарантируется что операции над дескрипторами потокобезопасны.
Так что так как у вас в первом примере делать вообще нельзя.

Плохо документированные особенности Linux

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

Уберите конкуренцию потоков и увидите что с сокетами все точно также как и с файлами:

    std::thread t1{[=]{ reader(s[0]); }};
    t1.join();
    std::thread t2{[=]{ reader(s[0]); }};
    t2.join();

Плохо документированные особенности Linux

Нет. В статье именно про потоки.

Если один из потоков решает закрыть свой сокет, другие потоки об этом ничего не знают, поскольку они на самом деле отдельные процессы и у них свои собственные копии этого сокета, и продолжают работать.

И процитирванное совершенно не соответствует действительности.

Плохо документированные особенности Linux

Про потоки и дескрипторы — не верю.

Проверка:

int main()
{
    int fd = ::open("/dev/zero", O_RDONLY);
    char buf[2];
    cout << ::read(fd, buf, 2) << endl;
    std::thread([&]() { ::close(fd); }).join();
    cout << ::read(fd, buf, 2) << endl;
    return 0;
}

Выводит:

2
-1

Т.е. дескриптор текущего потока, закрытый в другом потоке, закрыт и в текущем.

LibreOffice 4.4 рулит

Кстати, частично редактировать можно.
LO умеет открывать PDFы им же экспортированные.
Там можно подправить текст и экспортировать обратно.

Вам календарик на 2015-й

Нумерация должна с нуля начинаться. Стыдно не знать :)

Нисходящий парсер с операторным предшествованием

А «operator precedence» это разве не «приоритет операций»?

Сравнение Rust и С++ на примерах

Спасибо, направление понятно:
Инициализировать через atomic_compare_exchange_strong_explicit, а читать через atomic_load

Правда надо признать, shared_ptr тут не нужен. Можно обойтись простым указателем :)

Сравнение Rust и С++ на примерах

5) Многопоточность. Решается введением shared_ptr

Как?

Робот от Double Robotics: протестировано на людях

Лет через 20 над этими роботами будут смеяться

Уже смеются — например в сериале «Хорошая жена» хорошо так посмеялись над нелепостью такого устройства :)
www.youtube.com/watch?v=N9TpHGLj0yA

Method chaining

Задумался.
Пойду перечитаю стандарт :)

Method chaining

Нет.
См. мой ответ habrahabr.ru/post/215059/#comment_7385513

Method chaining

Формулировка другая, но в применении к данному вопросу она дает то же результат.
То что раньше называлось точками следования (sequence point), теперь называется упорядочиванием (sequencing). Что по сути является тем же самым, только позволяет еще описывать поведение неупорядоченного (unsequenced) кода.
Т.е. когда мы говорим что два выражения упорядочены это то же самое что в старом стандарте что между выражениями есть точка следования.

Таким образом интрепретация нового текста стандарта в старых терминах такая:

every value computation and side effect
associated with any argument expression, or with the postfix expression designating the called function, is
sequenced before execution of every expression or statement in the body of the called function

Это означает существует точка следования между вычислением всех аргументов функции и ее непосредственно выполнением.

Таким образом как старом так и в новом стандарте, вычисление аргументов для двух последовательно идущих в коде функций производится раздельно (если сами вызовы между собой упорядочены, как в данном случае).

Method chaining

Дело в том, что хотя стандарт и гарантирует, что process() будет вызвана перед print_result(), но не гарантируется, что перед аргумент функции print_result будет вычислен после выполнения process().

Вы ошибаетесь.

Стандарт гарантирует следующее:

When calling a function (whether or not the function is inline), there is a sequence point after the evaluation
of all function arguments (if any) which takes place before execution of any expressions or statements in
the function body. There is also a sequence point after the copying of a returned value and before the execution
of any expressions outside the function11)

Таким образом аргументы второй функции не могут быть вычислены до аргументов первой, т.к. они разделены двумя точками следования (sequence point).

Эксперимент по проверке библиотеки glibc

С точки зрения компилятора код

XDR *xdrs = &clp->xdr_stream;

эквивалентен коду

XDR *xdrs = &((*clp).xdr_stream);

Т.е. в этом коде разыменование — это вот это:

clp->

А взятие адреса там уже после разыменования.

Американские учёные создали искусственные мышечные волокна из обычной рыболовной лески

Подозреваю, что больше чем циклов записи у SSD :)

Skype 4.2.0.13 — минорный релиз с долгожданным фиксом

Потому что мейнтейнер PulseAudio, Леннарт Поттеринг — криворукий е#лан.
При внесении новых фич не только не заботился об обратной совместимости, но даже считал это достоинством пульса.

Идеальное собеседование айтишника

гуру, как правило, обладает огромным опытом прохождения собеседований

Это что за гуру такие? Гуру по прохождениям собеседований? :)