[RFC PATCH 1/6] server: Allow calling async_handoff() with status code STATUS_ALERTED.

[Jinoh Kang]

On 1/27/22 21:02, Jacek Caban wrote:
> 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?

The patchset is about sock_recv(), although I suppose sock_send() needs fixing as well.

> 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).

For small packets it seems like a good idea.  We still need to handle scatter/gather I/O though.

> 
> 
> Thanks,
> 
> Jacek
> 


-- 
Sincerely,
Jinoh Kang