[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.
- Re: Asynchronous DNS, Andy Moreton, 2016/02/01
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/01
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/01
- Re: Asynchronous DNS, YAMAMOTO Mitsuharu, 2016/02/01
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/01
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/02
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/02
- Re: Asynchronous DNS,
Eli Zaretskii <=
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/03
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/04
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/04
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/05
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/05
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/06
- Re: Asynchronous DNS, Eli Zaretskii, 2016/02/06
- Re: Asynchronous DNS, Alain Schneble, 2016/02/06
- Re: Asynchronous DNS, Lars Ingebrigtsen, 2016/02/06
- Re: Asynchronous DNS, Alain Schneble, 2016/02/07