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

[Matt Peterson]

Derek,

On Monday 28 January 2002 05:09 pm, Derek Atkins wrote:
> Matt,
>
> The issue is exactly what you said:  interruping read() or write().
> A process that calls a read() can wind up blocking in this same
> code.  If you send the process a signal (e.g. SIGINT) while it's
> sitting in this loop, your proposed patch will, in effect, cause the
> process to lose that signal.
>
> This is a Bad Thing (TM).  The only time you want to always ignore the
> signal is in the afsd processes.

FYI, with the current code, a signal that is sent to a process blocking in 
read() or write() _does_not_ properly return to the calling process.
Instead it enters the same endless loop.  evp->seq is periodically 
incremented by an afsd process so work does get done, but at the expense of 
100% of the cpu.  

You're right, with my patch, the syscall still does not return to the calling 
process, but at least it does not loop tightly in afs_osi_Sleep().

> See kolya's proposed patch which does have this property.  

Where do I get this patch?  From what I've seen of the libafs code so far, it 
is going to have to be much more involved that what I've proposed.  I'd like 
to see it.

-- 
Matt Peterson
Sr. Software Engineer
Caldera, Inc
matt@caldera.com