bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libpager deadlock


From: Sergio Lopez
Subject: Re: libpager deadlock
Date: Thu, 8 Apr 2010 16:07:20 +0200

El Thu, 8 Apr 2010 13:55:33 +0200
Samuel Thibault <samuel.thibault@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)?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]