Messages in this thread | | | Date | Sat, 13 Apr 2002 01:21:42 +0100 | From | Jamie Lokier <> | Subject | Re: [PATCH] zerocopy NFS updated |
| |
David S. Miller wrote: > I'm not advocating more locking in read() -- there's no need, and it is > quite important that it is fast! But I would very much appreciate an > understanding of the rules that relate reading, writing and truncating > processes. How much ordering & atomicity can I depend on? Anything at all? > > Basically none it appears :-) > > If you need to depend upon a consistent snapshot of what some other > thread writes into a file, you must have some locking protocol to use > to synchronize with that other thread.
Darn, I was hoping to avoid system calls. Perhaps it's good fortune that futexes just arrived :-)
In some ways, it seems entirely reasonable for truncate() to behave as if it were writing zeros. That is, after all, what you see there if the file is expanded later with a hole.
I wonder if it is reasonable to depend on that: -- i.e. I'll only ever see zeros, not say random bytes, or ones or something. I'm sure that's so with the current kernel, and probably all of them ever (except for bugs) but I wonder whether it's ok to rely on that.
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |