emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Asynchronous DNS


From: Eli Zaretskii
Subject: Re: Asynchronous DNS
Date: Wed, 03 Feb 2016 17:50:59 +0200

> From: Lars Ingebrigtsen <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Wed, 03 Feb 2016 11:50:29 +1100
> 
> erc does the following on connection:
> 
> (make-network-process :name name :buffer  buffer
>                       :host host :service service :nowait t)
> ...
> (when (fboundp 'set-process-coding-system)
>   (set-process-coding-system process 'raw-text))
> 
> That function starts with:
> 
>   CHECK_PROCESS (process);
>   p = XPROCESS (process);
>   if (p->infd < 0)
>     error ("Input file descriptor of %s closed", SDATA (p->name));
>   if (p->outfd < 0)
>     error ("Output file descriptor of %s closed", SDATA (p->name));
> 
> And now, :nowait returns even before infd/outfd has been set, which
> means the async DNS isn't as invisible to the user as I had hoped...
> 
> We could fix up the callers, of course, but that's a kinda yucky thing
> to do.  Perhaps my original thought of having a separate :asynchronous
> parameter to make-network-stream is a better idea for backwards
> compatibility?  Or...  :nowait 'dns, perhaps.  Then the libraries that
> want a fully async connection can say that explicitly by changing their
> ":nowait t"'s to ":nowait 'dns"?

We could remove these sanity checks (in this and many other
process-related APIs), they are not strictly necessary, at least not
in that function, AFAICS.

But I think a better approach is to make all those APIs that check or
need a fully-functional process object to wait for DNS completion
before they proceed.  That would be fully backward-compatible, at the
price that the callers will need to be changed to actually take
advantage of this feature.  Which I think is a Good Thing, because for
any application code that wants the async DNS we need a human to
seriously consider all the implications and modify the code
accordingly.  Evidently, this isn't something that can be
transparently changed under the hood.



reply via email to

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