[OpenAFS-devel] Very simple patch for libafs CPU hog on signal

[Nickolai Zeldovich]

> 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