Roland McGrath <[EMAIL PROTECTED]> writes:
> We do. The virtual copying behavior is enabled by a Boolean argument to
> vm_map. The issue is having several mappings together as an atomic unit
> relative to intervening write calls (or modifications via shared
> mmap).
One could get the (suckish)
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> For shared libraries, we use MAP_COPY. Maybe we can use this for
> executables, too?
That is what we do, but the present issue is different; we're talking
only about atomicity: that is, if you write the file, then your exec
is either the pre-write
> Linux doesn't allow any writes to shared libraries or executables that are
> currently running:
We know. It sucks wet goat farts.
> For shared libraries, we use MAP_COPY. Maybe we can use this for
> executables, too?
We do. The virtual copying behavior is enabled by a Boolean argument to
v
On Sat, May 11, 2002 at 04:40:36PM -0400, Roland McGrath wrote:
> AFAIK other systems do not always
> provide this guarantee, e.g. none I'm aware of do for NFS; I don't know
> whether other current systems in fact make the guarantee for disk files.)
> I'm not saying it's not a worthwhile thing to
> Only that it's essentially untested, and really deprecated. Roland, do
> you think it's worth keeping around? Is there another way to guarantee
> correct exec behavior? (Like, say, reading the entire file in a single
> RPC; is that enough?)
I didn't realize that the io_map_cntl stuff was dep
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> It seems that the shared I/O code is not really tested and a bit dated.
> Thomas, do you remember any unresolved issues about it?
Only that it's essentially untested, and really deprecated. Roland,
do you think it's worth keeping around? Is there
Hi,
I think I found the following missing locking in libiohelp:
2002-05-11 Marcus Brinkmann <[EMAIL PROTECTED]>
* handle_io_release_conch.c (iohelp_handle_io_release_conch):
New variable USER_SH. Hold USER_SH->lock while checking conch
status.
See the below patch. H
