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

Окей, грубо говорить, что к потоку

Окей, грубо говорить, что к потоку

по сути, система вызывает указанный программистом коллбек вне контекста какого-либо потока процесса

по сути, система вызывает указанный программистом коллбек вне контекста какого-либо потока процесса

для линукса это не совсем так: 'A signal may be generated (and thus pending) for a process as a whole (e.g., when sent using kill(2)) or for a specific thread (e.g., certain signals, such as SIGSEGV and SIGFPE, generated as a con‐ sequence of executing a specific machine-language instruction are thread directed, as are signals targeted at a specific thread using pthread_kill(3)). A process-directed signal may be delivered to any one of the threads that does not currently have the signal blocked. If more than one of the threads has the signal unblocked, then the kernel chooses an arbitrary thread to which to deliver the signal.' (c) man 7 signal. Хотя в чистом posix (man 2 signal) это вообще 'The effects of signal() in a multithreaded process are unspecified.'

для линукса это не совсем так: 'A signal may be generated (and thus pending) for a process as a whole (e.g., when sent using kill(2)) or for a specific thread (e.g., certain signals, such as SIGSEGV and SIGFPE, generated as a con‐ sequence of executing a specific machine-language instruction are thread directed, as are signals targeted at a specific thread using pthread_kill(3)). A process-directed signal may be delivered to any one of the threads that does not currently have the signal blocked. If more than one of the threads has the signal unblocked, then the kernel chooses an arbitrary thread to which to deliver the signal.' (c) man 7 signal. Хотя в чистом posix (man 2 signal) это вообще 'The effects of signal() in a multithreaded process are unspecified.'

хм, тогда отстал от жизни :(

для линукса это не совсем так: 'A signal may be generated (and thus pending) for a process as a whole (e.g., when sent using kill(2)) or for a specific thread (e.g., certain signals, such as SIGSEGV and SIGFPE, generated as a con‐ sequence of executing a specific machine-language instruction are thread directed, as are signals targeted at a specific thread using pthread_kill(3)). A process-directed signal may be delivered to any one of the threads that does not currently have the signal blocked. If more than one of the threads has the signal unblocked, then the kernel chooses an arbitrary thread to which to deliver the signal.' (c) man 7 signal. Хотя в чистом posix (man 2 signal) это вообще 'The effects of signal() in a multithreaded process are unspecified.'

Многопоточность же в каком-то там стандарте посикс описана, не?

В расширении если точнее

Которое поддерживают почти все

Кроме разве что жёсткого эмбеддеда

Многопоточность же в каком-то там стандарте посикс описана, не?

многопоточность-то да, pthreads — стандарт для unix-like, в общем-то. А вот с сигналами - хз.

Насколько я помню из прокуренного - потоки могут собственные правила обработки сигналов задавать

И приходят сигналы именно в потоки как единицы планирования выполнения

Насколько я помню из прокуренного - потоки могут собственные правила обработки сигналов задавать

могут, да. Но там это относится к pthread_kill, а не к kill. Вопрос в том, как именно ядро посылает сигнал.

Впрочем, в последнем "The Open Group Base Specifications Issue 7, 2018 edition" строки про "The effects of signal() in a multithreaded process are unspecified." уже нет. Хотя и всё равно не могу найти где она specified )

http://pubs.opengroup.org/onlinepubs/9699919799/

В предыдущем, "The Open Group Base Specifications Issue 6" она ещё есть )

http://pubs.opengroup.org/onlinepubs/009695399/functions/signal.html

Тогда такой вопрос: результаты на Intel64 и Amd64 коррелируют? Если на первом прирост скорости, то на втором тоже?

Тогда такой вопрос: результаты на Intel64 и Amd64 коррелируют? Если на первом прирост скорости, то на втором тоже?

Под Intel64 у меня первая ассоциация - IA64, он же Итаниум

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

Там немного отличается спекулятивное выполнение, но думаю будет нетривиально получить такую пару сниппентов кода, на которых у одного будет повышение, а у другого - замедление скорости работы.

Если это не самоцель, то различия можно свести на погрешность

Есть набор последовательностей которые могут на одной архитектуре выстрелить, их даже специально искать не нужно: обычный read-modify-write, можно легко попасть на такой порядок даже не задумываясь. Из типичного примера берутся рекомендации из гайда по оптимизации для одного процессора и они будут наверняка более неправильными с точки зрения производительности для другого

Если это не самоцель, то различия можно свести на погрешность

Итого при компиляции ядра линукс в один поток на амд медленней чем на интеле, причём хорошо так медленней. А при многопоточной компиляции медленней у интела.

Кто-то начинал курс на Coursera от яндекса?

Кто-то начинал. Спрашивай конкретнее

Интересует фин. помощь от Coursera, предоставляют на этот курс?

Интересует фин. помощь от Coursera, предоставляют на этот курс?

в смысле, заплатила ли Курсера Яндексу?

Кто-то начинал курс на Coursera от яндекса?

Иди в чатик курса

никто не пробовал делать что-то подобное на вариадиках? template <class... Ts> struct foo { virtual void method(Ts) = 0; // здесь где-то должно быть многоточие }; // чтобы для Ts = int, float, bool получилось struct foo { virtual void method(int) = 0; virtual void method(float) = 0; virtual void method(bool) = 0; };

никто не пробовал делать что-то подобное на вариадиках? template <class... Ts> struct foo { virtual void method(Ts) = 0; // здесь где-то должно быть многоточие }; // чтобы для Ts = int, float, bool получилось struct foo { virtual void method(int) = 0; virtual void method(float) = 0; virtual void method(bool) = 0; };

можно сделать N баз, у каждой под одному методу

можно сделать N баз, у каждой под одному методу

мне нравится, спасибо

только using Ts::method...; придется юзать, а он только с с++17

ну или рекурсивно наследовать

только using Ts::method...; придется юзать, а он только с с++17

у меня в задаче именно наличие виртуальных методов, которые обязаны быть переопределены в наследнике, так что всё ок: https://godbolt.org/z/yH2yGJ

Не знаю видели ли вы это предложение: http://wg21.link/P0989 Можно будет писать long long long int :)

Не знаю видели ли вы это предложение: http://wg21.link/P0989 Можно будет писать long long long int :)

?

тогда смысл пропадает от long long, он же с расширением разрядности тоже увеличивается

Не знаю видели ли вы это предложение: http://wg21.link/P0989 Можно будет писать long long long int :)

мне не нравится. Лучше явно указывать кол-во бит\байт

как это сделано в wide_int

+

мне не нравится. Лучше явно указывать кол-во бит\байт

+1

мне не нравится. Лучше явно указывать кол-во бит\байт

We also propose allowing the use of diacritics (on the o) for long and short. ie: lōng int x; == long long int x; shōrt int x; == long short int x; löng int x; == short long int x; о боже

We also propose allowing the use of diacritics (on the o) for long and short. ie: lōng int x; == long long int x; shōrt int x; == long short int x; löng int x; == short long int x; о боже

так вроде не 1 апреля

short long int j; // (1 + 1/0.5)(32) = 48 bits

:)

ну ладно, посмеялись и хватит :)

Не знаю видели ли вы это предложение: http://wg21.link/P0989 Можно будет писать long long long int :)

А модули как? Или после сентября тишина?

так вроде не 1 апреля

Document number: P0989R0 Date: 2018-04-01 а таки первое)

хай, сорри что сюда пишу, есть ли группа pro.android ?

https://t.me/joinchat/AAAAAEKIFKnmRT9cMebb9w

самое смешное из предложения (помимо диакритики): C++17 { int b12 : 12; int b5 : 5; } C++20 { long short short int b12; short long short short short int b5; }

Как-то не удобно

я уж испугался, что на волне diversity щас появятся куча пропозалов, которым нельзя будет отказать

Не знаю видели ли вы это предложение: http://wg21.link/P0989 Можно будет писать long long long int :)

а как же cstdint?

я уж испугался, что на волне diversity щас появятся куча пропозалов, которым нельзя будет отказать

а это идея...

а это идея...

сменишь предпочтения ради пропозала?

сменишь предпочтения ради пропозала?

всё во славу С++

Буду Александрой Зайцевой. Благо волосы уже отрастил. В комитете Беларусь представлять буду

всё во славу С++

как во славу C++ Сашей сразу назовусь

Не знаю видели ли вы это предложение: http://wg21.link/P0989 Можно будет писать long long long int :)

хе-хе, теперь следующая ошибка в GCC будет type long long long long int is to long

Не знаю видели ли вы это предложение: http://wg21.link/P0989 Можно будет писать long long long int :)

Что только не придумают, лишь бы Decimal не делать...

Не знаю видели ли вы это предложение: http://wg21.link/P0989 Можно будет писать long long long int :)

дичь

предлагаю по количеству букв l в слове long, дабы запись была короче

lllllllong

тяжело читается...

я б за wide_int голоснул бы :)

wide_int жеж

long 4 раза тоже неайс)

В бан всех, что ли.