lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <e7ca40f70706040720k48aae8efg7a4997ce1d6f2450@mail.gmail.com> Date: Mon, 4 Jun 2007 10:20:00 -0400 From: "Aaron Wiebe" <epiphani@...il.com> To: linux-kernel@...r.kernel.org Subject: Re: slow open() calls and o_nonblock Replying to David Schwartz here.. (David, good to hear from you again - haven't seen you around since the irc days :)) David Schwartz wrote: > > There is no way you can re-try the request. The open must either succeed or > not return a handle. It is not like a 'read' operation that has an "I didn't > do anything, and you can retry this request" option. > > If 'open' returns a file handle, you can't retry it (since it must succeed > in order to do that, failure must not return a handle). If you 'open' > doesn't return a file handle, you can't retry it (because, without a handle, > there is no way to associate a future request with this one, if it creates a > file, the file must not be created if you don't call 'open' again). I understand, but this is exactly the situation that I'm complaining about. There is no functionality to provide a nonblocking open - no ability to come back around and retry a given open call. > You need either threads or a working asynchronous system call interface. > Short of that, you need your own NFS client code. This is exactly my point - there is no asynchronous system call to do this work, to my knowledge. I will likely fix this in my own code using threads, but I see using threads in this case as working around that lack of systems interface. Threads, imho, should be limited to cases where I'm using them to distribute load across multiple processors, not because the kernel interfaces for IO cannot support nonblocking calls. I'm speaking to my ideal world view - but any application I write should not have to wait for the kernel if I don't want it to. I should be able to submit my request, and come back to it later as I so decide. (And I did actually consider writing my own NFS client for about 5 minutes.) Thanks for the response! -Aaron - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists