libev 3.8 threads & signals

[common at gmx.ch]

> 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