"Brent W. Baccala" <[email protected]> writes: > My solution is to signal the condition variable right before the call to > mach_msg, but this creates a race condition where messages can get > reordered. > > As you know, I never liked this blocking behavior of mach_msg, but I just > can't see any way around it now. If you can suggest something, let me > know...
If rpctrace could detect whether the memory_object_data_request RPC was caused by one of its threads, it could set the condition variable on behalf of that thread then. However, this won't work if rpctrace doesn't see the memory_object_data_request message. The original thread might have sent a memory_object_data_request message to a pager not traced by rpctrace, and that pager might then have sent a message to the traced task via a port wrapped by rpctrace. If rpctrace could ask Mach whether the thread that was supposed to call mach_msg is blocked because of a pager, that might solve this. IIRC, GNU Mach doesn't provide a way to ask that, but it shouldn't be too hard to add. rpctrace might have to inefficiently poll the flag though. Or examine the contents of the messages and use that to decide whether they can be safely reordered. In your example, vm_copy should be safe to reorder against both mach_port_deallocate and vm_allocate, if the address ranges and ports do not overlap. Or implement system call tracing in GNU Mach.
