From: Alexandre Julliard Subject: Re: [RFC PATCH 1/6] server: Allow calling async_handoff() with status code STATUS_ALERTED. Message-Id: <87wnilf61p.fsf@wine> Date: Thu, 27 Jan 2022 18:21:38 +0100 In-Reply-To: <2f792e83-688b-f541-5978-36aab3ed0ccc@codeweavers.com> (Zebediah Figura's message of "Thu, 27 Jan 2022 10:53:44 -0600") References: <29a9011d-e9c6-cb7a-73aa-9859be53d4f5@gmail.com> <71dcdb24-b2af-5fc3-bd2f-6df0b75a7f6e@codeweavers.com> <2f792e83-688b-f541-5978-36aab3ed0ccc@codeweavers.com> "Zebediah Figura (she/her)" writes: > On 1/27/22 06: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? >> 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). > > That's actually a good point, thanks for making it. I think I actually > did consider this when first moving things around, but decided against > it on the grounds of keeping stuff out of the server... > > Note that we do have to deal with scatter/gather, and the control and > address in recvmsg, so it can't quite do a generic ioctl, we'd still > need to use a special async I/O proc on the ntdll side. But it does > obviate the need to change the async infrastructure at all. > > One possible concern is that we'd end up doing a lot of large copies > over the server request sockets. It's not clear to me if that's > anything to worry about. I think that's a concern, yes. You'd also need large buffers on the server side. It would of course make some things easier, but I'm not sure it's a good idea. -- Alexandre Julliard julliard@winehq.org