[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:19:43 +0300 |
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.
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
- [PATCH glibc] Stop checking if MiG supports retcode., Flavio Cruz, 2023/05/10
- Re: [PATCH glibc] Stop checking if MiG supports retcode., Sergey Bugaev, 2023/05/10
- Re: [PATCH glibc] Stop checking if MiG supports retcode., Flávio Cruz, 2023/05/15
- Re: [PATCH glibc] Stop checking if MiG supports retcode.,
Sergey Bugaev <=
- Re: [PATCH glibc] Stop checking if MiG supports retcode., Sergey Bugaev, 2023/05/15
- Re: [PATCH glibc] Stop checking if MiG supports retcode., Flávio Cruz, 2023/05/16
- Re: [PATCH glibc] Stop checking if MiG supports retcode., Sergey Bugaev, 2023/05/16
- Re: [PATCH glibc] Stop checking if MiG supports retcode., Flávio Cruz, 2023/05/19
- Re: [PATCH glibc] Stop checking if MiG supports retcode., Sergey Bugaev, 2023/05/19
- Re: [PATCH glibc] Stop checking if MiG supports retcode., Flávio Cruz, 2023/05/26
- Re: [PATCH glibc] Stop checking if MiG supports retcode., Guy-Fleury Iteriteka, 2023/05/26
- Re: [PATCH glibc] Stop checking if MiG supports retcode., Flávio Cruz, 2023/05/27
- Re: [PATCH glibc] Stop checking if MiG supports retcode., Guy-Fleury Iteriteka, 2023/05/27
- Re: [PATCH glibc] Stop checking if MiG supports retcode., Sergey Bugaev, 2023/05/26