POSIX signals и треды

Ты в гугл смотрел?

https://cschleiden.wordpress.com/2011/09/09/sigprof-signal-handler-and-pthreads/ - пробовал так же сделать?

http://stackoverflow.com/questions/12952262/signal-handler-function-in-multit...

Вот там есть такой ответ:

Signal handlers are per-process state - that is, all the threads in a process share the same set of installed signal handler functions.

Signal masks are per-thread state. Signals can be blocked or unblocked on a per-thread basis.

Signals can be process- or thread-directed. If a signal is process-directed, then an arbitrary thread which does not have the signal blocked is chosen to handle it.

A simple way to handle signals in a multi-threaded application is to create one thread as a dedicated signal-handling thread. All signals of interest are blocked in every thread; no signal handlers are established; and the signal-handling thread calls sigwaitinfo() in a loop, acting on the signals as they're received.

then an arbitrary thread which does not have the signal blocked is chosen to handle it.

Тогда как получается, что все треды по твоей ссылке получили ~1000 сигналов? В чём магия? Как я понимаю, в лучшем случае должно быть ~1000/4 сигналов на тред, а в худшем 1000 сигналов на один тред и 0 на другие

Внутренняя ванга подсказывает мне, что у SIGPROF не POSIX семантика.

Похоже ты прав, заменил SIGPROF на SIGTERM и стал killall'ить. В итоге сигналы получал только 1 тред

В чём магия?

Да какая разница. Работает - и хорошо. Да, это скорее всего особенность SIGPROF

Вот как у него получились такие ровные значения? я попробовал пример (только изменил ф-цию idle_time), разброс процентов в 10

я попробовал пример (только изменил ф-цию idle_time), разброс процентов в 10

Аналогично.

tailgunner, AptGet

Вот ещё проблема - мне из обработчика нужно записать измерения в специальную структуру. Так как в многонитевых процессах из обработчиков сигналов нельзя изменять shared объекты кроме volatile sig_atomic_t, структура планируется своя на каждый процесс. Но как получить к ней доступ из обработчика. Тот же pthread_getspecific можно считать в том же линуксе async-signal-safe?

Я бы из обработчика писал нужные данные в файловый дескриптор, это безопасно. А уже в другой нити/процессе менял что там требуется поменять с синхронизацией, как положено.

Тот же pthread_getspecific можно считать в том же линуксе async-signal-safe?

Не знаю насчет линукса, в позиксе ни одна pthread_ функция не безопасна, если я правильно помню.

Не знаю насчет линукса, в позиксе ни одна pthread_ функция не безопасна, если я правильно помню.

Точняк, но походу она работает

http://pastebin.com/xe4T6zui

Можешь попробовать запустить у себя. Тот чувак по первой ссылке в треде запускал у себя pthread_self и вроде тоже ничего так

У меня на уме только один вариант, в котором сигнал будет получать главный тред, потом он каким-то образом приостановит остальные и соберет с них инфу. Как остановить несколько тредов сразу в один момент?

POSIX, AFAIK, так и рекомендует делать — ловить сигналы в одном, выделенном для этого потоке (главном, например). А потом обрабатывать их соответствующим образом.

Ну и SIGSTOP/SIGCONT.

https://github.com/sbcl/sbcl/blob/master/contrib/sb-sprof/sb-sprof.lisp

Вон в sbcl вообще в sigprof-handler мьютекс держится, такие дела

Если делать втупую, то я плюсую запись данных в дескриптор. Другое дело, что для профайлера это слишком высокие накладные расходы... поищи какой-нибудь lockless алгоритм. Насколько я понимаю, тебе нужно просто записать небольшую порцию данных в общую память?

структура планируется своя на каждый процесс

На процесс или нить?

$ ./thread2 
Signals caught after 4x10 seconds by thread 0: 905 
Signals caught after 4x10 seconds by thread 1: 4 
Signals caught after 4x10 seconds by thread 2: 917 
Signals caught after 4x10 seconds by thread 3: 880 

На линуксе работает, в смысле запускается, но нужно проверять, правильно ли оно считает.

$ ./thread2 
Signals caught after 4x10 seconds by thread 0: 50 
Signals caught after 4x10 seconds by thread 1: 0 
Signals caught after 4x10 seconds by thread 2: 0 
Signals caught after 4x10 seconds by thread 3: 0 

На макоси явно сломано.

Вон в sbcl вообще в sigprof-handler мьютекс держится, такие дела

Я могу представить как сделать чтобы оно работало, но проблема UB в том что полезавтра Дреппер чуть подправит магнитное поле glibc и код сломается, а Дреппер даже версию библиотеки не поднимет. И формально будет прав, как и в случае с memcpy.

как и в случае с memcpy

А шо там с мемкопи поменялось? Я не сишник, потому не вкурсе, но интересуюсь.

Изменение поведения memcpy в glibc привело к странным ошибкам

На процесс или нить?

На нить, да.

Насколько я понимаю, тебе нужно просто записать небольшую порцию данных в общую память?

Угу

Молодец этот ваш Дреппер, чо. Пусть быдлокодеры соснут

тебе нужно просто записать небольшую порцию данных в общую память?

Угу

Тогда тебе нужна атомарная операция «увеличить счетчик на N и вернуть предыдущее значение». Если не заморачиваться увеличением объема общей памяти на ходу, должно хватить.

Signals caught after 4x10 seconds by thread 1: 4

На бзде вообще всё ровно. Можно будет приводить это как аргумент в пользу бзди в срачах против ляликсоидов ;)