On Mon, May 15, 2023 at 9:19 AM Sergey Bugaev <buga...@gmail.com> wrote: > On Mon, May 15, 2023 at 7:09 AM Flávio Cruz <flavioc...@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 :) Sergey
