[Top][All Lists]

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

Re: [PATCH glibc] Stop checking if MiG supports retcode.

From: Sergey Bugaev
Subject: Re: [PATCH glibc] Stop checking if MiG supports retcode.
Date: Mon, 15 May 2023 09:49:13 +0300

On Mon, May 15, 2023 at 9:19 AM Sergey Bugaev <bugaevc@gmail.com> wrote:
> On Mon, May 15, 2023 at 7:09 AM Flávio Cruz <flaviocruz@gmail.com> wrote:
> > If we want
> > ./configure to check if MiG generates code to call the server reply routine
> > in case of errors (it doesn't :() then we will need to build a different 
> > check.
> Huh? Why would MIG call that? Maybe I'm missing some context.

Ah, I think I see what you might have meant.

Are you thinking that the xxxx_reply subsystem defines the proper,
canonical format for reply messages to the xxxx subsystem? -- and that
MIG should call those instead of doing its own logic for generating a
reply message?

If that's what you mean, then, well, no. The reply format for each RPC
is fully defined by its declaration in the xxxx.defs. Specifically: it
has msgh_id +100 compared to the request RPC, the first value in the
message body is the RetCode, and then all the out or inout arguments,
in order.

Moreover, there doesn't have to be a xxxx_reply subsystem
generated/compiled/linked into the server program. Those servers that
want it, they do use it, others don't.

xxxx_reply subsystem is fully independent from the original xxxx
subsystem as far as MIG is concerned. It's a *trick* (described in my
previous message) used by programs to make and handle requests
asynchronously *without* altering the wire/message format. The
xxxx_reply subsystem is supposed to *mimic* the format of xxxx
subsystem's reply messages, not *define* it. It should be completely
*transparent* to a client program that calls e.g. io_select, whether
the server implements it synchronously (as e.g. pflocal does) or
asynchronously (with MIG_NO_REPLY + an eventual io_select_reply, as my
epoll server implementation does). The retcode specifier in
xxxx_reply.defs is designed to fix the (hopefully only) difference in
wire format between actual replies of the xxxx subsystem and the
simpleroutines of the xxxx_reply subsystem.

I hope that makes sense. And if that's not what you've meant, please
explain what it was :)


reply via email to

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