| |||||||||||||
Ghosts of Unix past, part 3: Unfixable designsGhosts of Unix past, part 3: Unfixable designsPosted Nov 24, 2010 22:04 UTC (Wed) by neilbrown (subscriber, #359)In reply to: Ghosts of Unix past, part 3: Unfixable designs by foom Parent article: Ghosts of Unix past, part 3: Unfixable designs
I was wondering if you had brought this up with the developer of signalfd - Davide Libenzi?
Fixing it would probably require adding a new 'flags' option, so adding a new syscall and deprecating the old. This 'flags' could allow atomic setting of close-on-exec and an auto-block flag which causes all signals being tracked by signalfd to blocked just as long as the signalfd is open.
If you haven't and don't want to, I might....
Thanks,
(Log in to post comments)
Ghosts of Unix past, part 3: Unfixable designs Posted Nov 25, 2010 18:28 UTC (Thu) by dcoutts (guest, #5387) [Link]
Please do bring this up with the kernel hackers. We were thinking of using signalfd in the GHC runtime / IO system until we discovered this problem with having to block all signals in all threads which makes it unusable (it's not just child processes, libraries can make their own threads). We have to stick with the approach of installing a signal hander that writes to a pipe (or we can use eventfd for the cases where there is no data associated with the signal).
|
|||||||||||||