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,
Marcin 'Qrczak' Kowalczyk wrote:
Ben Rudiak-Gould [EMAIL PROTECTED] writes:
is there *any* way to get, without an exploitable race condition,
two filehandles to the same file which don't share a file pointer?
In unix the traditional way to do this is to use a directory. Each
Keean Schupke [EMAIL PROTECTED] writes:
At the end of the day IO is serial by nature (to one device anyway),
so the way to do this into one file is to have one thread that reads
and writes, and to 'send' read and write requests over channels from
the threads that need the work done
Would the
No I meant Channels (from Data.Concurrent)... you can use a structure like:
data Command = Read FileAddr (MVar MyData) | Write FileAddr MyData
So to write you just do:
writeChan iochan (Write address data) -- returns immediately
-- write happens asynchronously later
and to read:
data -
Ketil Malde wrote:
Keean Schupke [EMAIL PROTECTED] writes:
No I meant Channels (from Data.Concurrent)... you can use a structure like:
Yes, I realize that (although I haven't yet used Data.Concurrent). It
seemed to me, though, that streams are related to channels, and that
it may be
Ketil Malde [EMAIL PROTECTED] writes:
It seemed to me, though, that streams are related to channels,
I'm not sure what exactly do you mean by streams (because they are
only being designed), but differences are:
- A stream is either an input stream or an output stream, while a
single channel
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes:
Ketil Malde [EMAIL PROTECTED] writes:
It seemed to me, though, that streams are related to channels,
I'm not sure what exactly do you mean by streams (because they are
only being designed), but differences are:
Sorry for being unclear, I
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
Ferenc Wagner wrote:
dup()-ed filehandles share a common file position.
They also share the file status flags (O_NONBLOCK, O_APPEND etc). So,
enabling or disabling non-blocking I/O will affect all descriptors
obtained by duplication (either by dup/dup2 or by fork).
OTOH, each descriptor has
Marcin 'Qrczak' Kowalczyk wrote:
Ben Rudiak-Gould [EMAIL PROTECTED] writes:
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 [...]
This was all discussed a year ago, and
Simon Marlow wrote:
I assumed that dup()'ing file descriptors would be enough to produce
separate file pointers, but no.
Question (for qrczak or the group at large): is there *any* way to get,
without an exploitable race condition, two filehandles to the same file
which don't share a file
Ben Rudiak-Gould [EMAIL PROTECTED] writes:
is there *any* way to get, without an exploitable race condition,
two filehandles to the same file which don't share a file pointer?
AFAIK it's not possible if the only thing you know is one of the
descriptors. Of course independent open() calls which
12 matches
Mail list logo
