On Mon, May 15, 2023 at 2:19 AM Sergey Bugaev <buga...@gmail.com> wrote:
> 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. > 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 >
