From: Samuel Thibault <[email protected]> > Roy Marples, le dim. 07 juin 2026 18:55:40 +0100, a ecrit: > > I really dislike the small timeout just to add a cancellation point as it > > means > > there is a lot of context switching going on just because of this. > > Why the small timeout? doesn't cancellation interrupt mach_msg with an > infinite timeout, provided that we pass MACH_RCV_INTERRUPT. If not, it > rather looks to me like a bug to be fixed.
mach_msg is NOT a pthreads cancellation point when passed MACH_RCV_INTERRUPT. I would agree this is a bug that should be fixed. The workaround for the time being is to set pthreads async cancellation but disable cancellation around routines that manipulate resources - such as mutex lock/unlock and mallocing a new msg buffer. Works great, just more code and a big comment explaining this to anyone that cares to read it :) The big benefit for me NOT using libpcap for this is that I discovered that dhcpcd's ARP BPF code is too big to fit in the Mach kernel. The whole point of using BPF is so that dhcpcd doesn't have to wakeup and process every packet on the interface. And dhcpcd listens to ARP all the time so it can handle IPv4 DaD. Luckily i can drop checking that the ARP hardware length matches ethernet hardware length. Just too big by one BPF check! We already check ETHERTYPE_ARP and ARPHRD_ETHER so it should be safe. We perform a pull packet check in the code after BPF processing anyway as a double safely barrier mainly because Linux does not clear the incoming messages after setting a filter so it helps here too. Roy
