On Jul 1, 2004, at 1:23 AM, Dan Bernstein wrote:

In case the answer is "don't call mach_make_memory_entry in the first

place", how else can one task grant access to a piece of memory to

another task, so that the first task can later revoke that access?

Currently, I use vm_map, and that seems to require a map entry.

Once access is granted to others, there is no mechanism to revoke it. This makes sense, since the only mechanism the system would have to implement a revocation would be to raise a bus error if anyone accessed the revoked memory (or any copy-on-write of the revoked memory passed on to other system servers, etc...). So, in effect, revocation could easily be used to crash the whole system - not something we want in the hands of a regular application. The best way to do what [I think] you want is to map a private copy-on-write copy of the original range into the original application over top of itself so that your future modifications would not be seen by any of the others sharing the (old) range represented by the mach_make_memory_entry() handle. You can do this with either vm_protect(VM_PROT_COPY) or vm_remap(). The former is a little more efficient when all you want to do is get a private copy (with everything else being the same). The latter is much more flexible in what can be changed. --Jim [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.