Derek, On Monday 28 January 2002 04:28 pm, Derek Atkins wrote: > Question: what happens if you really DO want to interrupt the > process? Wont this cause it to fail to interrupt even when the > process returns from the AFS Syscall? >
I'm not sure I understand the question... I don't see any problems with cases where you really do want to interrupt the task from it's call to afs_osi_Sleep(). The proposed patch does absolutely nothing to affect the workings of calls made to afs_osi_Wakeup(). As you'll notice neither of these calls (afs_osi_Sleep() nor afs_os_Wakeup()) directly change the state of the "current" task. Changing the state of the "current" task is left to the kernel scheduler via the calls to interruptable_sleep_on() and wake_up(). Additionally, the processes that exhibit the tight loop problem are those that are buried in "daemon" syscalls -- they never return back to user space unless a terminating call is made via another syscall (i.e. unmount /afs) When a terminating call is made, *that* process grabs the afs lock and sets the data structures that cause the otherwise terminally looping "daemon" syscalls to exit. Then those processes "sleeping" in the looping "daemon" calls are woken via calls to afs_os_Wakeup(). No where in any of this are signals honored or cared about. Therefore, it seems safe to ignore them. In fact, there is code elsewhere in libafs that is intended to ignore all signals. The patch I propose is simply to ignore them in one more place where they are not being ignored. Now, if there is interest in actually making the afs syscalls respond appropriately to signals there appears to be a lot more work to do. This is what I meant by the following statement: > Matt Peterson <[EMAIL PROTECTED]> writes: > Still, signals are not handled the way I'd like them to be, but at least > with this fix, processes interrupted in certain libafs syscalls do not > completely hog the CPU. Specifically, I'd like to be able to interrupt process that are blocking in calls to read() and write(). This way I will be able to kill a copy (cp) or listing (ls) process that is taking too long because it is blocking in the afs kernel module. I'd be happy to discuss the pros and cons of various approaches to proper signal handling in libafs. Again, I haven't looked at all the code, but it looks like it might take a little work to streamline. I agree that this streamlining *might* mean changing the proposed patch, but for now, I don't think the patch does any harm to the legitimate wakeup code. -- Matt Peterson Sr. Software Engineer Caldera, Inc [EMAIL PROTECTED] _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
