> I know that there signals are lost with the patch. The point I was trying to > make (and I think we agree) is that it does not matter in cases where the > syscall is not capable of return to caller anyway.
Sure, it doesn't matter for afsd-initiated syscalls (which already block all signals anyway.) We do, of course, care about the case of a user-initiated syscall, like read(), and losing signals for that user process while waiting inside the syscall. > > It might be relatively simple, though, to implement interruptability > > for common cases, such as waiting in rx_Read or rx_Write, or waiting > > for a background daemon to complete the request. (Infact, the latter > > should be almost trivial.) > > I whole-heartedly agree. If there is interest in doing the work to > streamline existing syscalls that really should return to caller (I'm > interested) then the patch I propose would superceed these efforts as signals > would be lost. If there are not plans to streamline the code for signal > processing then I'll stick with my patch that ignores them all -- its better > than the CPU hog alternative... There's another alternative, which is the patch I sent to this list in response to your original message; it both avoids the CPU hog problem and doesn't lose signals, so regardless of whether the code will later be changed to be interruptible, or not, it'll be useful. As far as making the current code deal better with signals, probably a good place to start would be to try adding interruptability to the afs_UFSRead call, around the DFFetchReq/DFFetching waiting loop, which waits for the background daemon to finish the fetch. Probably we'd need to add another parameter to afs_osi_Sleep, like afs_osi_Wait's aintrok. -- kolya _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
