[PATCH v3 0/2] MR135: Cancel asyncs queued by thread when the thread is terminated

[Zebediah Figura]

On 6/3/22 20:46, Paul Gofman wrote:
>> * If a thread dies naturally (terminates itself), we can cancel its
>> asyncs from the terminate_thread handler, and then, in the client side
>> but before calling exit_thread(), do a zero-length wait with
>> SELECT_INTERRUPTIBLE, exactly as in v1 of this patch set. My
>> understanding is that these alone are actually sufficient to ensure
>> that any APC_ASYNC_IO resulting from the async termination are
>> executed by the thread itself before it frees its stack. I.e. we don't
>> need any of the "queue_only" bits that were in v1. This holds because:
>>
>>    - terminate_thread doesn't set the state to TERMINATED yet in the
>> "self" case;
> 
> Yes.
> 
> 
>>
>>    - as a result queue_apc() will queue the (system) APC to that
>> specific thread;
> 
> It will not put it to the queue, it will send SIGUSR1. As (without the
> long and probably ugly part which was in v1 of the patch) it puts the
> APC in queue only if the thread is waiting in server select or already
> has some APC in queue. The other way (probably not super nice as well)
> would be to put APC_NONE to the thread system APC queue, then the logic
> in queue_apc() would queue our async cancels to the queue as well.

I don't understand what you mean by this. Sending SIGUSR1 doesn't mean 
that the async isn't queued; it's still put into the system_apc list. 
SIGUSR1 doesn't carry the async as a payload or anything, it's just a 
way to force the thread to check its own queue. Am I missing something here?

The way I see it, the exiting thread will select manually, and it'll 
also be sent SIGUSR1. If SIGUSR1 comes first, that'll trigger a select, 
and the system APC(s) will be consumed. If the manual select comes 
first, the same thing happens, and then it doesn't matter whether the 
SIGUSR1 is received or if it comes too late and gets masked off.