Hi, 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. 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. 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