From: "Zebediah Figura (she/her)" Subject: Re: [RFC PATCH 1/6] server: Allow calling async_handoff() with status code STATUS_ALERTED. Message-Id: Date: Thu, 27 Jan 2022 16:58:49 -0600 In-Reply-To: <49e9478c-02f6-57c0-366c-353c697505f9@gmail.com> References: <29a9011d-e9c6-cb7a-73aa-9859be53d4f5@gmail.com> <49e9478c-02f6-57c0-366c-353c697505f9@gmail.com> On 1/27/22 02:44, Jinoh Kang wrote: >> What we need to do here is similar to the infrastructure that already exists for device asyncs, namely "unknown_status" etc. It would be nice to use that instead of reinventing it, and although I haven't tried, it seems possible. > > That one was on the table, too. In fact it can also help eliminate the initial_status == STATUS_ALERTED check. > > One catch is that async_set_unknown_status also sets direct_result to 0, which means to always fire off APC on completion. > I wasn't entirely sure of what the effects of { .unknown_status = 1, .direct_result = 1 } would be. I believe that !direct_result is correct here, actually. Note that we only get an APC when calling async_terminate(), but we shouldn't be introducing any extra terminate calls. > >> >> async_add_queue() as it is above is not great. I'm not sure that code actually works in every case; > > !pending && terminated && alerted was the condition I was able to deduce to detect this exact condition. > It does sound a little arbitrary though, especially since it's testing for three unrelated conditions. > >> it definitely increases the mental burden even if it does. (Consider for instance that it would be triggered for *every* async). >> >> Instead what I'd suggest is to use the request introduced here in every case, even if the initial status was pending. > > You mean, along with use of unknown_status? In a sense they're orthogonal, but yes, I think doing both would help.