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

[Flávio Cruz]

On Mon, May 15, 2023 at 2:19 AM Sergey Bugaev <bugaevc@gmail.com> wrote:

Hi,

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. Here's
my understanding of what the retcode specifier is for:

The use cases for the xxxx_reply subsystems are:

* On the client/user side, only sending the request as a simpleroutine,
  and then handling the eventual reply, asynchronously, as a request in
  its own right (S_xxxxx_reply).
* On the server side, returning MIG_NO_REPLY from a routine
  implementation, and then replying asynchronously using the xxxx_reply
  simpleroutine.

The special handling for retcode arguments is needed to:

* On the server side, when calling xxxx_reply (this is the *user* side
  as far as MIG is concerned), if the RetCode is non-0, MIG should not
  serialize all the other arguments into the message, just like it
  normally does when a server-side routine implementation returns
  non-0.
* On the client side, when handling an incoming xxxx_reply request
  (this is the *server* side as far as MIG is concerned), MIG should
  not reject the request on the basis of a failed type/size check if
  its RetCode is non-0, because this is how error replies are supposed
  to be. It should still call the routine implementation
  (S_xxxx_reply), passing either zeroes out, or I guess just garbage
  values would work as well, for the missing arguments.

Yes, I meant this when I said "generate code to call the server reply routine

in case of errors".

Take the example of the term translator, it forces TypeCheck to be 0 so that

it can still receive replies in the error case (otherwise BAD_TYPECHECK would fail).

MiG itself should generate an updated stub code that first checks the

return code and, in case of error, assume the message has the shape of

mig_reply_header_t. I believe term currently gets garbage values for all

other missing arguments.

 

This MIG_NO_REPLY + asynchronous explicit reply pattern is rarely used
on the Hurd; most of the servers are written to just block the routine
implementation on a conditional variable or something like that, and
reply synchronously. Which is probably why we've been able to get away
with not supporting retcode properly.

Sergey