Ben Rudiak-Gould writes:

http://www.haskell.org/~simonmar/io/System.IO.html

"fileRead :: File -> FileOffset -> Integer -> Buffer -> IO ()" This is unimplementable safely if the descriptor is read concurrently by different processes. The current position is shared. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

Ben Rudiak-Gould writes:

fileRead can be implemented in terms of OS primitives,

Only if they already support reading from a fixed offset (like pread). I'm not sure if we can rely on something like this being always available, or whether it should be emulated using lseek which is safe only as long as we are the only process using the given open file. 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.

and it's easy enough to implement a thread-safe seek/read interface on top of it.

Not if it must cooperate with other processes, and you *do* want to set a file position before running another program with redirected standard I/O. In this case it's not enough that you set a private Haskell variable holding its logical file position - you must perform the lseek syscall. Doing something differently than everybody else has a risk of limited interoperability, even if the new way is "better", and thus must be carefully evaluated to check whether all lost functionality is unimportant enough to lose. BTW, on Unix sockets and files are the same, but probably not on Windows. I don't know details about WinAPI. I know that basic file I/O uses HANDLEs, winsock uses ints which emulate Unix descriptors; what I don't know is whether you can also use HANDLEs for sockets (perhaps each winsock fd has an associated HANDLE with easy translation in both directions? or is there another API for sockets on HANDLEs?) and how do you perform redirection of standard I/O, in terms of HANDLEs or what - in particular I don't know whether you can redirect standard I/O to a socket. How should Haskell view this? I mean that on Unix it should somehow make files and sockets interchangeable, in order to support I/O redirection for programs being run; but it's not easy if you use completely different interfaces for files and sockets, as the streams proposal seems to do. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

Ben Rudiak-Gould writes:

First of all, I don't think any OS shares file pointers between processes.

Unix does. It's because shared files are usually stdin/stdout/stderr (I mean that they are visible as stdin/stdout/stderr, rather than about their nature as terminals - they may be regular files), which are usually accessed sequentially without seeking. Quite often they are not seekable at all (terminals or pipes), which means that they behave as if the file pointer was always positioned at the end (for writing) or beginning (for reading) and shared. If they are seekable, the position is shared so you can redirect I/O to a process running subprograms.

Otherwise it would be practically impossible to safely use an inherited filehandle via any API.

Pipes are not seekable and always behave as if the position is shared. It doesn't make them impossible to safely inherit. They are inherited on fork because they are anonymous objects, so it's the only way to connect them; after fork most programs close the reading end in one of the processes and the writing end in the other. It's rare that two processes read from the same pipe or write to the same pipe. If they do, one of them is usually a helper program started by the other, and the other waits for the helper to finish. If you want two processes to access the same file indepenently, pass a file name and open it twice.

The file interface in this library is only used for files, which are always seekable (by definition).

What do you mean by files? What you get from open() is not always seekable, because it's not always a regular file. The name may refer to a device (whether it's seekable depends on the particular device; block devices are seekable but most character devices are not, e.g. /dev/ttyS0, /dev/lp0 - serial and parallel ports) or to a named pipe (not seekable). -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

Ben Rudiak-Gould writes:

Marcin 'Qrczak' Kowalczyk wrote:

...

Ben Rudiak-Gould writes:

...

fileRead can be implemented in terms of OS primitives,

Only if they already support reading from a fixed offset (like pread). I'm not sure if we can rely on something like this being always available, or whether it should be emulated using lseek which is safe only as long as we are the only process using the given open file.

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.

This may be what you wrote, but let me still put it: dup()-ed filehandles share a common file position. Handles straight from open() have independent file positions. fork() duplicates filehandles and the child inherits those => the child process shares the file position with its parent. Threads or processes doesn't make the difference; dup() or open() does. This is my interpretation of the docs, I didn't test it... :) -- Feri.

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 _are_ wrong :-(... POSIX quite clearly states that the file descriptors are duplicated by fork(), but the "open file descriptions" (your "file pointers") are shared. This is obvious by observing what happens when you write to the same fd in parent and child after a fork: you don't end up overwriting, you end up interleaving. --KW 8-) -- Keith Wansbrough http://www.cl.cam.ac.uk/users/kw217/ University of Cambridge Computer Laboratory.