[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)?
- Re: libpager deadlock, Sergio Lopez, 2010/04/07
- Re: libpager deadlock, Samuel Thibault, 2010/04/07
- Re: libpager deadlock, Sergio Lopez, 2010/04/08
- Re: libpager deadlock, Samuel Thibault, 2010/04/08
- Re: libpager deadlock,
Sergio Lopez <=
- Re: libpager deadlock, Samuel Thibault, 2010/04/08
- Re: libpager deadlock, Sergio Lopez, 2010/04/09
- MIG documentation (was: libpager deadlock), Thomas Schwinge, 2010/04/09
- Re: MIG documentation (was: libpager deadlock), Samuel Thibault, 2010/04/09
- Re: MIG documentation, Thomas Schwinge, 2010/04/09