From: Jacek Caban <jacek@codeweavers.com>
Subject: Re: [RFC PATCH 1/6] server: Allow calling async_handoff() with status code STATUS_ALERTED.
Message-Id: <71dcdb24-b2af-5fc3-bd2f-6df0b75a7f6e@codeweavers.com>
Date: Thu, 27 Jan 2022 13:02:14 +0100
In-Reply-To: <f024a573-b042-9610-0d62-58c371b4ea26@codeweavers.com>
References: <dbbb078d-22c6-a24d-b906-5d3bd694bce4@gmail.com> <29a9011d-e9c6-cb7a-73aa-9859be53d4f5@gmail.com> <f024a573-b042-9610-0d62-58c371b4ea26@codeweavers.com>

On 1/27/22 00:52, Zebediah Figura (she/her) wrote:
> On 1/23/22 11:29, Jinoh Kang wrote:
>> +static int async_add_queue( struct object *obj, struct 
>> wait_queue_entry *entry )
>> +{
>> +    struct async *async = (struct async *)obj;
>> +    assert( obj->ops == &async_ops );
>> +
>> +    if (!async->pending && async->terminated && async->alerted)
>> +    {
>> +        /* The client has failed to complete synchronously (e.g. 
>> EWOULDBLOCK).
>> +         * Restart the async as fully fledged asynchronous I/O, where
>> +         * the completion port notification and APC call will be 
>> triggered
>> +         * appropriately. */
>> +        async->pending = 1;
>> +
>> +        /* Unset the signaled flag if the client wants to block on 
>> this async. */
>> +        if (async->blocking) async->signaled = 0;
>> +
>> +        async_set_result( obj, STATUS_PENDING, 0 );  /* kick it off */
>> +    }
>> +
>> +    return add_queue( obj, entry );
>> +}
>> +
>
> I'll admit, this kind of thing is why I didn't really want to have to 
> try to optimize 3 server calls into 2. Asyncs are already really 
> complicated, in terms of the many paths they can take, and it seems 
> like no matter what we do they're going to get worse. 


Did you consider moving whole sock_send() and try_send() to server? We 
could then have a proper and reliable queue in server socket object and 
client could just do a regular generic server ioctl. (I didn't really 
follow closely the conversation, so sorry if I missed something).


Thanks,

Jacek