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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
