Ben Rudiak-Gould <[EMAIL PROTECTED]> writes: > Marcin 'Qrczak' Kowalczyk wrote: >> Ben Rudiak-Gould <[EMAIL PROTECTED]> 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. _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
