Path: ...!3.eu.feeder.erje.net!feeder.erje.net!news2.arglkargh.de!news.karotte.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.unix.programmer Subject: Re: signal handling issues Date: Tue, 04 Feb 2025 18:55:25 +0000 Lines: 16 Message-ID: <87cyfxee02.fsf@doppelsaurus.mobileactivedefense.com> References: <874j1g18x2.fsf@doppelsaurus.mobileactivedefense.com> <20250130114503.356@kylheku.com> Mime-Version: 1.0 Content-Type: text/plain X-Trace: individual.net kfTfOy36hH3WyaQ3SsP3MgygOSmdvMXxCEMo8kG/KwQaMHgpw= Cancel-Lock: sha1:MArrG5UVkOSCP59k1kfJE9KqDkU= sha1:gvdYyy8vNb/j02LCCJHtc3hMJ2Y= sha256:M2yoOBpLH0uKKsu9Ll5XGxrH0zvxnGWicsCHl5Rc5hE= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Bytes: 1638 Muttley@dastardlyhq.com writes: > Lawrence D'Oliveiro gabbled: >>On Fri, 31 Jan 2025 09:15:39 -0000 (UTC), Muttley wrote: >> >>> All this confusion and complexity is why I always recommend that in a >>> multithreaded program if you must use signals then all signals should be >>> blocked with a single thread dedicated to sitting in sigwait() and handling >>> whatever comes along. >> >>Or use signalfd(2) . > > I never knew about that, very useful! Unfortunately it appears to be linux > only. I've started to use it exclusively in the last couple of larger programs I wrote for my employer.