> > 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 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
