On Wednesday, September 11, 2002, at 11:49 AM, Andrew Gallatin wrote: I could make all uses APPLE_API_PRIVATE headers go away in my driver (OS-Bypass cluster interconnect -- http://www.myri.com/scs/macosx.html) if somebody would just fix the VM system so that it wouldn't block a user process indefinatly if said process attempts to free memory locked via IOMemoryDescriptor's prepare function. But I couldn't seem to get anybody interested in changing this behaviour in the past... I think I even exchanged some mail with you on this subject last time. Doing what you ask would require "prepare" to create and hold its own reference to the underlying memory objects rather than "glom-ing" on to the user's reference (leaving the user free to release his own with impunity). This could be done, but it would slow prepare down even more in its current form (and it is in dire need of a performance boost already). In fact, we are in the process of investigating possible enhancements to the implementation. The leading design does involve burrowing all the way down to the object, so we do have the opportunity to think about taking our own references again. This would allow unprepare to be much more efficient, and subsequent prepares in the same object could also be quicker. But is also allows a possible redress of your issue. 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. --Jim PS: I think, last we left it, we also talked about changing the timing between file-descriptor closing and VM cleaning. We intentionally clean up the Mach port space (which IOKit UserClient interfaces typically use) before the VM space so that UserClient memory descriptors would be freed before attempting to free the memory in an exiting process. Closing file descriptors should happen even before that (to allow file-descriptor-based drivers to release their holds on memory). While this may not be necessary, if we do the work above, it is still the cleaner way to go. _______________________________________________ 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.