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

[Nickolai Zeldovich]

> >                                                        I think having
> > the signal delivered when the AFS syscall completes would be a better
> > solution.
> 
> I agree that it would be good to allow the app in user space to handle the 
> syscall.  The problem is that there are several syscall that NEVER return.

Those places already mask out all signals (current->blocked), to my
understanding.  This was just checked into CVS about a week ago, so
perhaps you're running an older version that doesn't do this.  The
remaining case where AFS would chew up CPU cycles is in `conventional'
syscalls like read(), which will eventually return, and we can handle
the signal then.

I think you might've missed my main point, though: in your patch,
signals sent to the process while it's waiting in AFS are lost, which
is probably a bad thing.

> The work to make sure that these syscalls return gracefully with the 
> appropriate errorcodes is going to take some work.

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.)

-- kolya