Re: ios steram flags vs ios_base stream flags
Denise Kleingeist wrote:
kanze wrote:
Denise Kleingeist wrote:
For example, I don't think that
POSIX systems can implement "noreplace" in general and
atomically. I'm not sure about "nocreate".
I'm not 100% sure what noreplace means, but wouldn't opening
with the options O_CREAT | O_EXCL do the trick?
I don't think it does. Here is an excerpt from Linux open(2):
Linux isn't Posix:-). I think it aims for Posix compliance
here, but the reference is the Posix standard. (The Posix
standard is available on line at
http://www.unix.org/single_unix_specification/.)
...
O_EXCL When used with O_CREAT, if the file already exists it is an
error and the open() will fail.
Isn't that what noreplace means?
In this context, a symbolic link exists, regardless of where
it points to. O_EXCL is broken on NFS file systems; programs
which rely on it for performing locking tasks will contain a
race condition.
...
It would be interesting to hear more about the "brokenness" of
NFS; taken literally, it would mean that you cannot implement
Posix over NFS. But I don't think it's relevant with regards to
C++ -- C++ doesn't currently acknowledge the existance of other
threads or processes (and without other threads or processes,
race conditions can't possibly exist).
To be fair, I actually wasn't of this flag!
Note that there are other flags which might be important in
some applications as well: Posix has various synchronization
options, for example, and in my work (but this is very
domaine specific), I rarely open a file without some of
them. (Which means that I cannot use iostream on the files.
I don't know how this conclusion derives from what you stated!
I can see that you can't use std::ifstream and family but what
exactly prevents you from creating a suitable stream buffer
using whatever open flags and read/write operations you need?
True. Given the importance of the synchronous (and atomic)
write, it just seemed more reasonably to use ostrstream
(actually, an omemstream, since the ostrstream provided with Sun
CC doesn't work correctly with a user supplied buffer) to format
into an std::vector<char>, then write that in one atomic
operation. Especially as the start of the record contains the
length and a CRC checksum, which I do not know until I've
finished formatting everything else.
The IOStreams library is created to be extensible in various
ways, an important way being new sources and destinations. Of
course, I'm aware that you know this since you have posted
often enough about how to create stream buffers. I'm thus
somewhat surprised of your analysis above!
A bit superficial, I'll admit, since in fact, I do use ostream
for formatting. A custom omemstream, in fact. But I don't
think that the ostream idiom is really appropriate for managing
the records as such on the disk; part of the abstraction is that
things like buffering are transparent, where as in this case, I
definitly want to manually control the exact moment the data is
written to disk---a partial write because the buffer is full is
not acceptable.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]