Re: Question abut DRQ handler

Yuxin Ren <[email protected]>
Newsgroups gmane.comp.micro-kernel.l4.devel
Message-ID <CAAKbDrc751Kzh4rH4E-cyk26Hqy161F9C5j_tocxKe+kVeXdcQ@mail.gmail.com>
Thank you very much.
I have a further question.
For simple data-only IPCs, do we still need 4 IPIs?


On Thu, Jun 26, 2014 at 4:38 PM, Adam Lackorzynski <
[email protected]> wrote:

> On Tue Jun 24, 2014 at 15:43:06 -0400, Yuxin Ren wrote:
> > When I go through the IPC code, I have some questions about dqr handler.
> > In the remote_ipc_send function within the thread-ipc.cpp file, I find a
> > comment
> >
> > "  // trigger remote_ipc_receiver_ready path, because we may need to grab
> > locks
> >   // and this is forbidden in a DRQ handler. So transfer the IPC in usual
> >   // thread code. However, this induces a overhead of two extra IPIs."
> >
> > I have some questions about this comment.
>
> I'm not fluent in this part but I'll try.
>
> > 1. Why cannot we grab locks in a DRQ handler?
>
> Because those handlers must not block.
>
> > 2. Where do we need to grab lock?
>
> When the IPC does transfer some items processing those might require to
> take locks, for example, when mapping pages. Will not happen for simple
> data-only IPCs.
>
> > 3. Why can extra IPI solve this problem?
>
> Because in this case the receiver will handle the IPC instead of the
> sender and the IPIs are there for telling the receiver about that.
>
>
>
> Adam
> --
> Adam                 [email protected]
>   Lackorzynski         http://os.inf.tu-dresden.de/~adam/
>
> _______________________________________________
> l4-hackers mailing list
> [email protected]
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>

_______________________________________________
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.