Re: Asynchronous DNS

[Alain Schneble <a.s@realize.ch>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Sat, 06 Feb 2016 18:49:43 +1100
>> 
>> I kinda think we've gotten as far as we're going to get in this
>> discussion, and that it's time to merge.
>
> I'm sorry, but I disagree.  I think the APIs that expect a fully
> functional process object should wait for the DNS resolution to
> complete, before they do anything.

FWIW, the process-send-* functions do not wait for an async connection
to complete either, even without async-DNS-feature turned on.  They
throw an error if called before the async connection completed, IIUC.
And the documentation does not mention anything about this behavior.

It seems to me like it is a matter of definition to say which functions
should work properly also before an async connection is established and
which not.

If backward compatibility were not an issue, we could also adopt a more
restrictive approach where errors would be thrown in many of the
functions accepting a (async socket) Lisp process and requiring a valid
infd/outfd before async connection completion.  Documentation of
`make-network-process' could say something like "if :nowait is t,
process returned shall not be used in any call before async connection
has completed.  Consider performing any required process configuration
withing the SENTINEL".  Oops, just realized that this is what Lars more
or less put in the doc string for the 'dns case...

Just as an overview, here is an extract of functions relying on a valid
infd/outfd and hence would be candidates that could either throw errors
or, as you suggested, synchronously wait for the DNS resolution to
complete.  There are quite a few though:

`process-contact', `set-process-filter', `set-process-filter-multibyte',
`set-process-window-size', `set-network-process-option',
`set-process-coding-system', `process-filter-multibyte-p',
`process-datagram-address', `set-process-datagram-address',
`process-send-region', `process-send-string', `process-send-eof'

>> There should be no impact on any existing use.  It should be 100%
>> backward compatible.
>
> But it isn't, as was demonstrated by ERC.  And it cannot be 100%
> backward compatible, unless the above-mentioned waiting is added to
> the affected APIs.

I think what Lars meant was that with :nowait to t, client code should
be 100% backward compatible, as async connection establishment is still
handled the same way internally.

Only when :nowait is 'dns, the new async DNS resolution is activated.
And only in this case, we might run into /new/ issues with calls to
functions accepting a Lisp process, such as the issue revealed by ERC
before Lars introduced 'dns.

On one hand, I see the practical approach with the 'dns async mode to
circumvent these compatibility issues.  On the other hand, I don't think
it's a good choice from a interface/usage point of view.  I think it is
not clear for a user why she has to care about whether both async DNS
and async socket connection or only the latter shall be used and why the
process behavior is different.  This distinction only makes sense with
the knowledge of how it's implemented internally, I think.

I guess changing the semantics of :nowait t, to say that clients shall
not use the returned process before connection is established, is out of
discussion, right?  Or do you think that this would even be a ridiculous
restriction (even without the backward compatibility issue)?