[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Asynchronous DNS
From: |
Alain Schneble |
Subject: |
Re: Asynchronous DNS |
Date: |
Fri, 12 Feb 2016 11:12:15 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (windows-nt) |
Lars Ingebrigtsen <address@hidden> writes:
> By the way, the "make all process functions wait until the connection
> has been set up" will make functions that currently are non-blocking
> become blocking. For instance, erc creates a :nowait t connection, and
> then calls set-process-coding-system immediately. And then it sets up a
> sentinel that will complete login once the connection changes to 'open.
>
> Unless I'm misreading the code, making functions like that blocking will
> make stuff that's currently quite asynchronous become more asynchronous.
You mean less asynchronous. Or more synchronous. :) You are right, I
also think it would if the function waits for full connection set up.
> We could fix that, of course -- there's really no reason for that
> function to be checking infd/outfd, I think? But this is something that
> has to be done on a function by function basis unless we want
> regressions in how asynchronous :nowait t connections are.
Currently, IINW, `set-process-coding-system' calls
`setup_process_coding_systems' which basically requires infd/outfd to
/complete/ its "task". Otherwise it just returns. Later in the flow,
`connect_network_socket' will be called and it invokes
`set_network_socket_coding_system' near the end which in turn invokes
`setup_process_coding_systems'. So it looks like it will complete the
"task" anyway. But wait, AFAICS, in this case, the encodings that were
specified in the initial call to `set-process-coding-system' will be
overwritten, right? Hence, I don't think it will work properly if we
just do not check for infd/outfd...
Another approach could be to just wait until the socket has been
initialized (instead of connected), i.e. wait on a more fine grained
(internal) process state than just wait for 'run. Not sure, but async
TLS handling could benefit from such a state as well. Of course, we
kind of have it already implicitly, e.g. with p->dns_requests for
example.
As you said, after all, we'll have to look at each case in detail.
- Re: Asynchronous DNS, (continued)
- Re: Asynchronous DNS, Alain Schneble, 2016/02/08
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/08
- Re: Asynchronous DNS, Alain Schneble, 2016/02/09
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/09
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/09
- Re: Asynchronous DNS, Alain Schneble, 2016/02/09
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/09
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/09
- Re: Asynchronous DNS, Alain Schneble, 2016/02/10
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/11
- Re: Asynchronous DNS,
Alain Schneble <=
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/12
- Re: Asynchronous DNS, Alain Schneble, 2016/02/13
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/13
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/14
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/14
- Re: Asynchronous DNS, Stefan Monnier, 2016/02/14
- Re: Asynchronous DNS, Alain Schneble, 2016/02/14
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/14
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/14
- Re: Asynchronous DNS, Alain Schneble, 2016/02/14