On Jul 24, 2007, at 4:23 PM, Sarah Bailey wrote: > On Tue, Jul 24, 2007 at 03:09:43PM -0700, Zach Brown wrote: >> On Jul 24, 2007, at 1:17 PM, Sarah Sharp wrote: >> >>> When an AIO operation is cancelled >> >> So, the sad story is that the cancellation support in fs/aio.c is a >> mess. Before we get lost on those details can we talk about simply >> not allowing cancelation of these usbfs2 aio read requests? If they >> guarantee forward progress then you can just do what dio does. Don't >> set ki_cancel, they'll eventually complete. > > If the cancellation code is such a mess, why not include a comment > saying so, or remove it?
Well, I can't claim to speak on behalf of the others who are capable of rolling that patch but who haven't. For me, it's two things. First there have been much more serious aio +dio bugs to work on. (panics on io errors, that kind of thing). Secondly, we can nickle and dime ourselves to death fixing buglets in the current implementation. I'm preferring to work towards a design which renders much of the current code simply unnecessary, bugs included. > Could you comment on how syslets or fibrels would handle transfer > requests when the file position is ignored? I'm very interested in > ditching in-kernel AIO. syslets don't know a thing about whether system calls work with file positions or not. The rules are pretty simple: When you execute a syscall via a syslet it executes in the submitting task. If it completes without blocking then it's just as though you called the system call directly. If the system call blocks then the scheduler calls clone(). The parent of the cloned thread continues executing the system call. The child returns to userspace as having the syslet submission system call return. So userspace controls the degree of concurrency in the pending syscalls. Children who return on behalf of blocked parents can keep submitting syscalls as long as they can tolerate concurrency. If they can't, they wait for dependent syscalls to complete before continuing on. Does that answer the question? - z ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
