468,537 Members | 1,917 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,537 developers. It's quick & easy.

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

Nov 14 '05 #1
5 3367
JG <ja*********@gmail.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.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"Insanity is to be shared."
- Tailgunner
Nov 14 '05 #2
In article <cu**********@oravannahka.helsinki.fi>,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:
:JG <ja*********@gmail.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)
Nov 14 '05 #3
In article <11*********************@g14g2000cwa.googlegroups. com>,
JG <ja*********@gmail.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
Nov 14 '05 #4
In article <cu**********@canopus.cc.umanitoba.ca>,
Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:
|In article <11*********************@g14g2000cwa.googlegroups. com>,
|JG <ja*********@gmail.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.
Nov 14 '05 #5
On Fri, 04 Feb 2005 22:05:38 +0000, Walter Roberson wrote:
In article <cu**********@canopus.cc.umanitoba.ca>,
Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:
|In article <11*********************@g14g2000cwa.googlegroups. com>,
|JG <ja*********@gmail.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.programmer. 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.programmer.

Lawrence

Nov 14 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Pete | last post: by
36 posts views Thread by Roman Mashak | last post: by
AdrianH
1 post views Thread by AdrianH | last post: by
5 posts views Thread by yinglcs | last post: by
2 posts views Thread by DJ Dharme | last post: by
2 posts views Thread by TP | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.