On 12 January 2005 01:27, Ben Rudiak-Gould wrote:
First of all, I don't think any OS shares file pointers between processes. Otherwise it would be practically impossible to safely use an inherited filehandle via any API. Different threads using the same filehandle do share a file pointer (which is a major nuisance in my experience, because of the lack of an atomic seek-read/write), but a Posix fork duplicates the file pointer along with all other state. I can't believe I'm wrong about this, but someone please correct me if I am.
I'm afraid you're wrong. Believe me, I'm as surprised as you. See the definition of "Open File Description" in POSIX: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#t ag_03_253
This limits the problem to a single process. If you're only using GHC's lightweight threads, there's no problem at all. If you're using OS threads, the worst thing that could happen is that you might have to protect handle access with a critical section. I don't think this would lead to a noticeable performance hit when combined with the other overhead of file read/write operations (or lazy evaluation for that matter).
pread requires that the file is seekable, which means that it can't be used for all file handles: not for pipes, sockets, terminals nor various other devices.
The file interface in this library is only used for files, which are always seekable (by definition). If you want to treat a file as a stream, you create an InputStream or OutputStream backed by the file. Such streams maintain internal (per-stream) file pointers.
Unfortunately, they don't (at least in my prototype implementation). I assumed that dup()'ing file descriptors would be enough to produce separate file pointers, but no. So you can only safely make a single stream from a File. Making multiple streams would require re-opening the file for each subsequent one, or keeping a cached copy of the file pointer and seeking when necessary. Cheers, Simon