[tcpdump-workers] Re: SIGINFO/SIGUSR1 and SIGUSR2

2024-03-28 Thread Denis Ovsienko
On Thu, 28 Mar 2024 15:28:00 -0700 Guy Harris wrote: > On Mar 28, 2024, at 2:19 PM, Denis Ovsienko > wrote: > > > Yes, AIX and Haiku sometimes make portability issues manifest. > > And, in this case, Solaris doesn't have SIGINFO, either; SunOS > 0.x-4.x didn't have it, as BSD hadn't picked

[tcpdump-workers] Re: SIGINFO/SIGUSR1 and SIGUSR2

2024-03-28 Thread Guy Harris
On Mar 28, 2024, at 2:19 PM, Denis Ovsienko wrote: > Yes, AIX and Haiku sometimes make portability issues manifest. And, in this case, Solaris doesn't have SIGINFO, either; SunOS 0.x-4.x didn't have it, as BSD hadn't picked it up, and they didn't pass it along to be put into SVR4, so it's not

[tcpdump-workers] Re: SIGINFO/SIGUSR1 and SIGUSR2

2024-03-28 Thread Denis Ovsienko
On Thu, 28 Mar 2024 12:44:29 -0700 Guy Harris wrote: > > [--siginfo=] (on platforms with SIGINFO only) [...] > so I suspect few, if any, UN*Xes have, or had, SIGINFO without also > having SIGUSR1 and SIGUSR2. Thank you for providing the historic background. The above was supposed to mean

[tcpdump-workers] Re: SIGINFO/SIGUSR1 and SIGUSR2

2024-03-28 Thread Guy Harris
On Mar 28, 2024, at 3:01 AM, Denis Ovsienko wrote: > There is a rather old pull request at [1], which was supposed to make > use of the then-unused SIGUSR2, but whilst it was waiting, another pull > request used the signal for another code path. > > There is a potential way to manage this kind

[tcpdump-workers] SIGINFO/SIGUSR1 and SIGUSR2

2024-03-28 Thread Denis Ovsienko
Hello all. There is a rather old pull request at [1], which was supposed to make use of the then-unused SIGUSR2, but whilst it was waiting, another pull request used the signal for another code path. There is a potential way to manage this kind of contention by naming the available actions and