Michael Kelly, le mer. 01 avril 2026 00:10:49 +0100, a ecrit: > On 31/03/2026 21:48, Samuel Thibault wrote: > > Mike Kelly, le mar. 31 mars 2026 21:26:42 +0100, a ecrit: > > > An interrupted RPC call can return EINTR whilst the RPC is still in > > > progress on the server. Some RPC calls have permanent consequences > > > (eg. a write() to append data to a file) but a caller seeing EINTR > > > should expect that no state has changed. The signal thread now stores > > > the server's reply (which it already waited for) as the interrupted > > > thread's reply. > > The principle looks good to me, just a catch here: > > Oh dear, that was a bit silly. Had I been thorough enough to test on both > hurd-i386 and hurd-amd64 that would have been immediately obvious. > > It's slightly more complicated than mapping one register on i386.
Ah, right, it's on the stack. > There is > actually almost the right arch specific code available already in > MSG_EXAMINE defined per arch version of intr-msg.h. That macro supplies the > message header id rather than the message header itself though. > > Are you happy for me to just change that interface to provide the header > pointer? Yes, that'll be fine! > It is only called in one place in glibc and I can't imagine it's > used anywhere else? Using that macro has the benefit of catching relevant > memory faults in which case I can return EIEIO as in other internal failure > cases. Indeed. Samuel
