From: Jinoh Kang Subject: Re: [PATCH 4/4] dlls/ntdll: Call try_recv inside sock_recv only if it is safe to do so. Message-Id: Date: Wed, 19 Jan 2022 11:41:41 +0900 In-Reply-To: <79db4b01-6ad1-f9ac-1d1e-09471c61f2d8@gmail.com> References: <79db4b01-6ad1-f9ac-1d1e-09471c61f2d8@gmail.com> On 1/19/22 11:30, Jinoh Kang wrote: > As you can see this inevitably winds up tweaking the select mechanism > anyway. This approach has some open questions: > > 1. How shell we return the results for our new pseudo-APC call? > Using prev_apc in the select request, or a separate server call? > > 2. Shall our pseudo-APC go through the system_apc queue? > If so, what if there is another kernel APC that is already queued? > > 3. Shall we reuse invoke_system_apc() for this apc_call_t response? > > 4. Shall we reuse queue_apc() to generate the apc_call_t? > If so, what shall be done with the gratuitous SIGUSR1 delivery? > Enter uninterrupted region or explicitly block SIGUSR1 while > calling receive_sock? Further remarks: - If we lean toward "don't reuse anything," we're left with a bunch of APC bureaucracies with no apparent merits. - If we lean toward "reuse as much as possible," we would be left with some nontrivial refactoring work to do regarding select calls (e.g. injecting prev_apc to server_select/server_wait, special casing the "synchronous APC"). -- Sincerely, Jinoh Kang