On 2005-01-11, Simon Marlow
On 11 January 2005 14:15, Gracjan Polak wrote:
Simon Marlow wrote:
There's a big lock on File. If you want to do truly concurrent reading, > you can make multiple FileInputStreams, each of which has its own file > descriptor (the Unix implementation uses dup(2)).
Original and descriptor returned by dup or dup2 share file pointer.
*blink*
You're right! Serves me right for assuming that POSIX would have sensible semantics. Perhaps this API isn't implementable, in its current state.
Others have pointed out pread() and pwrite(); Perhaps we can stick this function in an extension package. (Though it is required for Unix 98 conformance, so anything reasonable will have it. Hmm. Does open("/dev/fd/n") or ("/proc/self/fd/n") act as dup() or a fresh open() to underlying file?) I actually don't see the problem with interacting with other processes that we've forked. Other processes using our image and runtime can arrange to use something sharable for locking. Other processes not doing this can change the bytes in the file, so that we're not guaranteed that we get what we expect anyway, unless we have full control over that process. In which case we can have it do whatever we want. -- Aaron Denney -><-