[Haskell-cafe] Re: I/O interface
simonmar at microsoft.com
Wed Jan 12 05:33:12 EST 2005
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:
> 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
> 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
> overhead of file read/write operations (or lazy evaluation for that
> >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
More information about the Haskell-Cafe