Сигналы + потоки

>ЗЫ: на послкдних ядрах линукса (2.6.25) ps на многопоточное приложение выдает одну >строчку, а ведь вроде потоки реализованы как полтоправные процессы через clone(2) >почему ps -aux мне их все не показывает или какую там опцию для этого надо указать?

потоки были реализованы как процессы во времена 2.4, и уже несколько лет как это не так.

>Теперь вопрос КАК таким образом (т. е. через sigwait и отдельный поток) поймать сигнал
>который по дефолту игнорится, ну например SIGCHLD?

поставьте обработчик и сигнал перестанет игнориться,
в обработчике сигнала сделайте write в pipe,
а в ожидающем сигнала потоке вызовете select/poll на pipe

> ЗЫ: на послкдних ядрах линукса (2.6.25) ps на многопоточное
приложение выдает одну строчку, а ведь вроде потоки реализованы как
полтоправные процессы через clone(2) почему ps -aux мне их все не
показывает или какую там опцию для этого надо указать?

$ uname -a
Linux fc 2.6.18-92.el5 #1 SMP Tue Jun 10 18:49:47 EDT 2008 i686 i686 i386 GNU/Linux

$ man ps | grep thread
To get info about threads:
                with -L, the NLWP (number of threads) and LWP (thread ID)
H               Show threads as if they were processes
-L              Show threads, possibly with LWP and NLWP columns
-T              Show threads, possibly with SPID column
m               Show threads after processes
-m              Show threads after processes
tables, kernel stack, struct thread_info, and struct task_struct. This is
l    is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
lwp        LWP      lwp (light weight process, or thread) ID of the lwp being
nlwp       NLWP     number of lwps (threads) in the process. (alias thcount).
                    on individual threads. Use the m option or the -m option
thcount    THCNT    see nlwp. (alias nlwp). number of kernel threads owned by
                    process is multi-threaded and ps is not displaying
                    threads.

$ ps aux | grep mysqld | wc -l
3

$ ps auxH | grep mysqld | wc -l
12

// wbr

> Изучение Стивенса во втором издании by Раго навело на такую вот мысль: Хорошо в отдельном потоке я догу дождаться доставки сигнала впри помощи sigwait с нужной маской. Ладно во всех остальных потоках я этот сигнал заблокирую, так что по теории и POSIXу он будет доставляться нужному потоку (да кстати как с этим утверждением в Linux, а то что-то мне подсказывает что хреново).

с этим утверждением в Linux все замечательно. если конечно вы уже успели перейти с 2.4.1 на что-то поновее.

> Для того чтобы sigwait отловил сигнал он должен доставляться процессу, то есть его диспозиция не равана SIG_IGN и он по дефолту не игнорится. Если на сигнал повешен обработчик то в зависимости от реализации вызовется либо он (обработчик) либо sigwait вернет управление... Теперь вопрос КАК таким образом (т. е. через sigwait и отдельный поток) поймать сигнал который по дефолту игнорится, ну например SIGCHLD? Причем гарантированно поймать и именно sigwaitом?

http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#ta...

// wbr

Не спасибо конечно за ссылку, но она не проясняет ответа на вопрос: Можноли <b>унифицированно</b> с помощью sigwait обработать любой (ну с точностью до SIGKILL, SIGSTOP и сигналов аппаратных ошибок) сигнал в отдельном потоке, или это возможно только для тех сигналов чьи действа по умолчанию нЕ SIG_IGN...

В 2.6 линуксе потоки тоже реализованны через clone(2) и они по сути являются отдельными процессами... просто было интересно починили доставку сигналов согласно POSIX или нет.

> ну с точностью до SIGKILL, SIGSTOP и сигналов аппаратных ошибок

на sigkill смертным не разрешается ставить обработчик.

> В 2.6 линуксе потоки тоже реализованны через clone(2) и они по сути являются отдельными процессами

с точки зрения шедулера разницы между тредом и процессом нет, и это нормально, но для создания треда clone вызывается с определёнными флагами, говорящими ядру, что новый процесс должен шарить адресное пространство с парентом.

> с точки зрения шедулера разницы между тредом и процессом нет

я бы даже сказал, что с точки зрения _ядра_ никаких потоков нет вообще
есть _группа потоков_, которая объединяет набор _процессов_
среди них есть лидер группы
с прикладной точки зрения его можно считать процессом, а все остальные процессы группы - потоками

http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html

LinuxThreads наконец-то уже в прошлом.