From: Jinoh Kang Subject: Re: [RFC PATCH v2 05/11] server: Add helpers for synchronous APC delivery via ordinary server call reply. Message-Id: <39d67b72-c8f8-eb98-b65c-0feb4de1fe58@gmail.com> Date: Wed, 26 Jan 2022 11:39:36 +0900 In-Reply-To: References: <1e0d520b-0f60-1323-3305-4f884fb121a1@gmail.com> <129a9a10-46b2-7ccf-3826-b0ca683a9c34@gmail.com> On 1/26/22 03:26, Zebediah Figura (she/her) wrote: > On 1/22/22 08:36, Jinoh Kang wrote: >> diff --git a/server/protocol.def b/server/protocol.def >> index db73f0418a9..f21f7187c4d 100644 >> --- a/server/protocol.def >> +++ b/server/protocol.def >> @@ -695,6 +695,13 @@ typedef union >>       } break_process; >>   } apc_result_t; >>   +typedef struct >> +{ >> +    apc_call_t   call;         /* APC call arguments */ >> +    obj_handle_t apc_handle;   /* handle to next APC */ >> +    int          __pad; >> +} inline_apc_t; >> + > > Why introduce this separate type? As for "why introduce this type at all": Otherwise we have to pass around two arguments (call and apc_handle) instead of one (inline_apc_t) everywhere. This also adds two parameters to select_wait(), and I was not sure about the idea of adding ", NULL, NULL" to every user except the async one. As for "why introduce a new type instead of using existing equivalent one": There's two substitute candidates: "struct queue_apc_request" and "struct select_reply". I'm not sure reusing them is allowed, though. Perhaps we can insert inline_apc_t inside those other two structs? -- Sincerely, Jinoh Kang