Joseph Galbraith <galb@xxxxxxxxxxx> wrote: > Axel Dörfler wrote: > > Joseph Galbraith <galb@xxxxxxxxxxx> wrote: > >> Unless I'm utterly wrong about filesystem I/O being pretty > >> much synchronous for linux and BeOS? > > BeOS device and file system I/O is synchronous only. But since a > > file > > system must be thread-safe and reentrant in BeOS anyway, having an > > asynchronous "backend" would probably be not that hard to support. > > I expect the problematic fields in the cache and VM area, although > > I > > can't really say since I haven't seen the Windows API. But porting > > to/ > > from Linux is probably harder than it is to port to/from Windows. > Ahh... > > So, if I understand correctly, during a read operation > (grossly simplified) it would work something like this. > > 1. App calls read > 2. Read syscall calls BeOS-fs layer (vfs layer?) > 3. vfs layer calls file system driver's read interface > 4. file system driver calls disk driver > 5. disk driver programs controller and waits for > data (blocking current thread.) > 6. OS runs other threads while controller thinks. Actually, the OS may run other threads at all times :-) > 7. Eventually controller interrupts saying data ready. > 8. Thread is unblocked and disk driver returns to > file system driver, which returns to vfs, which returns > to read syscall which returns to application. Exactly. > Under windows this looks like: > > 1. App calls read > 2. Read syscall calls I/O manager > 3. I/O manager calls file system driver's read interface > 4. Read interface calls disk driver, passing in a function > pointer to call when I/O is complete. > 5. Disk driver programs controller and returns immediately > with STATUS_PENDING (and no data.) > 6. File system driver returns STATUS_PENDING to I/O > manager, which propagates to the calling application. > 7. Eventually the controller interrupts saying data is ready. > 8. Disk driver calls I/O completion function in file system > driver. > 9. File system driver notifies the I/O manager that the > I/O is complete. > 9. I/O manager notifies application that I/O is complete. > > So, in order for existing BeFS file system driver code > to work on windows, it has to be changed to expect > function return from the disk driver with no data, > to return to it's caller w/ no data, and to expect > the disk driver to call it at some other entry point, > later, with the data. > > If BeFS could really be rearchitected to handle this > kind of thing without too much trouble, a port might > not be that bad. (And don't get me wrong, a BeFS > file system driver for windows would be way cool.) Actually, I am thinking of pulling the asynchronous I/O mechanism out of the disk driver system and into the OS directly, anyway. It wouldn't be too much of an effort, but I am not yet sure about how the API should look like. > Trying to do a wrapper which emulates the > VFS code so that the BeFS filesystem code can > run unchanged is even more problematic... it could > be done, but since the BeFS filesystem code > wants to block the thread, and windows doesn't > want the thread blocked, everything would have > to be marshaled into a thread that the wrapper > layer owns (and can safely block.) I don't think > this is going to win any performance contests, > though it might not be too bad. > > (The files system can block waiting for the disk driver > to call it's completion routine; it just isn't allowed > to block the calling thread in certain circumstances... > in other words, it isn't hard to turn the asynchronous > model into a synchronous one when permitted and > convenient.) Yes, but a different approach would definitely be appreciated :-) Bye, Axel.