bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tmpfs: now working


From: Niels Mller
Subject: Re: [PATCH] tmpfs: now working
Date: 17 Apr 2001 14:38:47 +0200

Roland McGrath <roland@gnu.org> writes:

> file being truncated to zero and then enlarged.  In fact, I believe (I'm
> not bothering to check POSIX even though the book is lying in front of me)
> the user is guaranteed that he can do:

If you ever bother to look it up, please let me know what you find.
(Or perhaps I should get that book for myself. What is a good POSIX
reference?)

>       write(file, "data", size)
>       ptr = mmap(file, 0, size)
>       access ptr -- see "data"
>       truncate(file) // could be ftruncate or via a wholly different peropen
>       access ptr -- see SEGV(BUS?) in a specified manner

That is quite a harsh behaviour. If you're right, it seems impossible
(I prefer to classify tricks like catching SIGSEGV as impossible) to
write programs that use mmap and fail gracefully on all i/o errors,
bad data, etc. An alternative would be to keep a map of an all-zero
page if the file is truncated. Would it make sense to have a flag to
mmap that enables a different behaviour?

I'm also a little curious about how it works in practice, I've heard
reports saying that reading mmap:ed memory never results in SIGSEGV,
and others saying that it really did segfault under some version of
Solaris when mmap:ed NFS-mounted files were truncated.

I'd be grateful if you or some other knowledgable person could clarify
this.

Regards,
/Niels



reply via email to

[Prev in Thread] Current Thread [Next in Thread]