syncronizing between two file descriptors open on the same file

[JG]

Hi all,

Does anyone know how the implementations on Linux and Windows handle
synchronization between a read and write FD open to the same file.

For example, if I have 2 FD open to file X.txt. 1 I use for reading,
the other for writing. If I write to position 125 on the write_FD,
call flush, and then turn around and read from the read_FD position
125, am I guaranteed to get the result I just wrote?

I could call sync (unix) or commit (win32) after each write, but that
would be a performance killer.

Thanks for the help.

Jacob

[Joona I Palaste]

JG <ja*********@gm ail.com> scribbled the following:

Hi all, Does anyone know how the implementations on Linux and Windows handle
synchronization between a read and write FD open to the same file.

I think people on Linux and Windows newsgroups would. As far as C
knows or cares, only one operation happens to a file at a time.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"Insanity is to be shared."
- Tailgunner

[Walter Roberson]

In article <cu**********@o ravannahka.hels inki.fi>,
Joona I Palaste <pa*****@cc.hel sinki.fi> wrote:
:JG <ja*********@gm ail.com> scribbled the following:
:> Does anyone know how the implementations on Linux and Windows handle
:> synchronization between a read and write FD open to the same file.

:I think people on Linux and Windows newsgroups would. As far as C
:knows or cares, only one operation happens to a file at a time.

I haven't looked at the C9x specs, but in C89, FD's are not part
of the language or library specifications. C89 talks only of
FILE* operations.
--
I don't know if there's destiny,
but there's a decision! -- Wim Wenders (WoD)

[Walter Roberson]

In article <11************ *********@g14g2 000cwa.googlegr oups.com>,
JG <ja*********@gm ail.com> wrote:
:For example, if I have 2 FD open to file X.txt. 1 I use for reading,
:the other for writing. If I write to position 125 on the write_FD,
:call flush, and then turn around and read from the read_FD position
:125, am I guaranteed to get the result I just wrote?

$ man fopen
However, output may not be directly
followed by input without an intervening fseek, fsetpos, or rewind.
Similarly, input may not be directly followed by output without an
intervening call to one of these functions, unless the input operation
left the file positioned at end-of-file.

The fflush() man page on the same system talks about fd's being
synchronized in some cases, but I would want to check out my X3.159
and POSIX.1 copies to see whether it would be usable for your purpose,
--
Entropy is the logarithm of probability -- Boltzmann

[Walter Roberson]

In article <cu**********@c anopus.cc.umani toba.ca>,
Walter Roberson <ro******@ibd.n rc-cnrc.gc.ca> wrote:
|In article <11************ *********@g14g2 000cwa.googlegr oups.com>,
|JG <ja*********@gm ail.com> wrote:
|:For example, if I have 2 FD open to file X.txt. 1 I use for reading,
|:the other for writing. If I write to position 125 on the write_FD,
|:call flush, and then turn around and read from the read_FD position
|:125, am I guaranteed to get the result I just wrote?

|$ man fopen
| However, output may not be directly
| followed by input without an intervening fseek, fsetpos, or rewind.

The C89 spec includes "fflush()" in that list of functions.

Note though that fflush() in the C89 spec is only defined to affect
output or update streams, so you cannot portably use fflush() to
synchronize between multiple fread()'s.

POSIX.1 does not define flush(). In POSIX.1 if you write() to a
fd that is not associated with a stream (e.g., you didn't use
fileno(FILE*) to get the fd and you didn't use fdopen() to promote
the fd into a FILE*), then you do not need to do anything in the
process that did the write(), but the process that will do the
read() needs to lseek() [or fseek()] before the reading takes place.

--
Oh, yeah, an African swallow maybe, but not a European swallow.
That's my point.

[Lawrence Kirby]

On Fri, 04 Feb 2005 22:05:38 +0000, Walter Roberson wrote:

In article <cu**********@c anopus.cc.umani toba.ca>,
Walter Roberson <ro******@ibd.n rc-cnrc.gc.ca> wrote:
|In article <11************ *********@g14g2 000cwa.googlegr oups.com>,
|JG <ja*********@gm ail.com> wrote:
|:For example, if I have 2 FD open to file X.txt. 1 I use for reading,
|:the other for writing. If I write to position 125 on the write_FD,
|:call flush, and then turn around and read from the read_FD position
|:125, am I guaranteed to get the result I just wrote?
If this is referring to POSIX file descriptors a good place top discuss it
is comp.unix.progr ammer. The concept of a file descriptor doesn't exist in
the C language itself.
|$ man fopen
| However, output may not be directly
| followed by input without an intervening fseek, fsetpos, or rewind.
fopen() is part of the C lannguage but the interface it provides does not
involve file descriptors.
The C89 spec includes "fflush()" in that list of functions.

Note though that fflush() in the C89 spec is only defined to affect
output or update streams, so you cannot portably use fflush() to
synchronize between multiple fread()'s.
In what sense do multiple freads() need synchronising?
POSIX.1 does not define flush(). In POSIX.1 if you write() to a fd that
is not associated with a stream (e.g., you didn't use fileno(FILE*) to
get the fd and you didn't use fdopen() to promote the fd into a FILE*),
then you do not need to do anything in the process that did the write(),
Ah ha
but the process that will do the read() needs to lseek() [or fseek()]
before the reading takes place.

It is dangerous to take advice that is off-topic in the newsgroup because
there may not be anybody else reading the newsgroup who knows enough or is
prepared to post corrections to errors. Again, this is best discussed in
comp.unix.progr ammer.

Lawrence