El Thu, 8 Apr 2010 13:55:33 +0200 Samuel Thibault <samuel.thiba...@gnu.org> escribió:
> Sergio Lopez, le Thu 08 Apr 2010 13:15:20 +0200, a écrit : > > > So it's really hung in the kernel. And indeed, even if from > > > the interface it would seem like it could be asynchronous, > > > the memory_object_lock_completed() call is done from the > > > memory_object_lock_request function itself... > > > > > > > But even if m_o_lock_completed is called from m_o_lock_request, that > > answer should come in another message, > > Right, but it still means that m_o_lock_request doesn't return before > having completed its job... > In memory_object.defs, m_o_lock_request is defined as simpleroutine, so a call to mach_msg_trap should only enqueue the message and return immediately. I don't have the stubs generated by MIG here, but the argument "option" should only have the MACH_SEND_MSG flag (you can check in GNU Mach's code that a call to mach_msg_trap with this flag, only enqueues the message and returns). Anyway, let's suppose that m_o_lock_request only returns when the process has been completed. Then, why do we need an interface to nofity its completion (m_o_lock_completed)?
