[RFC PATCH 1/6] server: Allow calling async_handoff() with status code STATUS_ALERTED.
Jacek Caban
jacek at codeweavers.com
Thu Jan 27 06:02:14 CST 2022
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
More information about the wine-devel
mailing list