libev 3.8 threads & signals
common at gmx.ch
common at gmx.ch
Fri Sep 25 15:51:45 CEST 2009
> You are right, g_thread_pool messes up the signals.
>
> rt_sigprocmask(SIG_BLOCK, [INT CHLD], NULL, 8) = 0
> syscall_289(0x5, 0x7fbf0d0606b0, 0x8, 0, 0x98, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0x5
> rt_sigprocmask(SIG_BLOCK, [HUP INT CHLD], NULL, 8) = 0
> syscall_289(0x5, 0x7fbf0d0606b0, 0x8, 0, 0x5, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0x5
Hrm, further invesigation shows that was libev signal handler code ...
The glib thing does not touch signal handler the signal handler directly:
mmap(NULL, 8392704, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f04a18e7000
mprotect(0x7f04a18e7000, 4096, PROT_NONE) = 0
clone(child_stack=0x7f04a20e7250,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7f04a20e79e0, tls=0x7f04a20e7950,
child_tidptr=0x7f04a20e79e0) = 27442
futex(0x24d5b90, FUTEX_WAKE_PRIVATE, 1) = 1
maybe the CLONE_SIGHAND got something to do with it?
As mentioned before, this worked fine with libev 3.6.
Markus
More information about the libev
mailing list