emacs-devel
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]