Hello, Roy Marples, le jeu. 11 juin 2026 09:44:50 +0100, a ecrit: > 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.
One can set async mode only around the mach_msg call for instance. > 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 Mach kernel? The network drivers rather live in netdde, and the bpf support comes from libbpf inside the hurd repository. If there is a limitation there it can very probably be lifted. Samuel
