Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> > Date: Sat, 15 May 2010 19:27:47 -0400 > From: Richard Pieri <richard.pieri-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> > Subject: Re: Asynchronous File I/O on Linux > To: Boston Linux and Unix <discuss-mNDKBlG2WHs at public.gmane.org> > Message-ID: <3B680037-E036-4210-8694-B08DEB7BD1F4-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> > Content-Type: text/plain; charset=us-ascii > > On May 15, 2010, at 5:56 PM, Mark Woodward wrote: > >> OK, so, the methodology is quite similar, fine. Now the question >> remains, is it possible to quickly "clone" an existing file handle so >> that it will be a new and distinct file handle with the same permissions >> and modes with its own distict view of current location, i.e. seek on >> one does not affect seek on the other? >> > > Part of the difficulty finding an answer is, I think, your incorrect use of "asynchronous I/O". This isn't it. What you've described is random access. > While I can see your point, it would be impossible to do multiple simultaneous requests without some sort of asynchronous I/O capability. The "random access" aspect of it comes out of using multiple file handles to a single file. > A file handle is really a pointer to a structure in the kernel somewhere that contains, among other things, the file read/write pointer. If you clone the descriptor then you get a pointer to the same structure. What you want is a completely new file handle for the same file. That's easy: open(). So you'd do something like: > > fh1 = open(filename, O_WRONLY, mode); > fh2 = open(filename, O_WRONLY, mode); > readblock(block,size,offset,fd1); > readblock(block,size,offset,fd2); > close(fd1); > close(fd2); > No offense Richard, and I know it is a habit I tend to share, unfortunately, but offering remedial instruction in response to question is almost never productive: the ignorant won't listen and the knowledgeable don't need it. Besides, you probably mean O_RDWR or O_RDONLY, O_WRONLY won't work in your example. > I think. > > --Rich P. > >
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |