Jim Magee writes:

...

...

The real question is: Does anything depend upon that portion of the

...

...

address space being locked down while I/O is in progress? It would be

...

...

difficult to see how they could, because the prepare gets released

...

...

before their notion of an I/O operation is marked as complete. But

...

...

it's just something to investigate.

...

...

Nothing depends on that part of the address space being locked down.

I didn't really mean in your specific case. I meant in general, since

this is a general API.

I meant in general. I can't see how any application behaviour would change, except to possibly get faster. Right now, a process which frees wired memory is stopped in its tracks until the memory is unwired. Eg, it never has a chance to do any work until after the free() or munmap() completes. With the new behaviour, the application would be able to return from the free/munmap call immediately, but the contents of its address space at the point where control returned to it would be the same as the old way. It would just get to return quicker. The only ramification I can see is if some driver wanted to touch the data that had been transferred. Eg, the driver wires the user memory, initiates the dma, the dma completes, and it fondles the bits that were just dma'ed to/from userspace, then it unwires the memory. Of course, that hypothetical driver should have also mapped the memory into the kernel to do the fondling, or it should be doing a copy{in,out} so it should still be safe... Drew _______________________________________________ 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.