Re: how to save a file to memory rather to disk?
On Mar 29, 8:35 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
On Mar 28, 3:36 pm, James Kanze <james.ka...@gmail.com> wrote:
On Mar 28, 5:38 pm, zl2k <kdsfin...@gmail.com> wrote:
Please allow me to clarify the question. In my code it generates a jpg
image, and another api will consume the jpg. I can write the jpg to
disk as "abc.jpg" and pass that to the consumer program, but that may
cost IO time.
Or it may not. On most systems, if the file isn't too big, and
is deleted quickly enough after it is written, it may never hit
the disk. Or you can use shared memory---but if the data hangs
around enough in shared memory, it may end up on disk. In
general, the OS makes the decision about such things, not you
(although you can generally force it when necessary, e.g. for
reasons of transactional integrity).
Allow me to take disagreement with your points in parentheses. From
what little reading I've done, ensuring an actual flush to non-
volatile storage on POSIX OSs and win32 is not easy. Across all
platforms, you do not have a real-life guarantee that sync, fsync, and
fdatasync force the data to non-volatile storage. The last time I
researched this problem, I learned that there are no easy answers. It
depends on the exact OS, its current configuration, its available non-
standard APIs, and whether or not your exact hard disk model and hard
disk driver want to play nice.
Well, it's not portable, that's for sure. And my actual
experience in this domain is limited to Solaris Sparc. But as
long as the disk was local (no NFS involved), it seemed to work.
Or perhaps we were just lucky.
Posix does make specific requirements, as well; presumably, a
system where it didn't work wouldn't be Posix compliant. But of
course, there are always bugs, and if you're remote mounting
drives, the system is dependent on what the protocol provides,
and how well the remote host complies, regardless of what Posix
says, or even how well it has been written itself.
In short, I suggest that people do their research before attempting to
write some software with guarantees in the face of failures from power
loss or other catastrophic program or OS failures.
Definitly. It's important to understand the specific platform
you're programming to, and what guarantees it actually gives.
And to maintain a good deal of scepticism; I'm not aware of any
specific issues with NFS, for example, but as soon as two or
more entities are involved, I become very mistrustful.
--
James Kanze