GNU bug report logs - #78920
30.1; Process sentinel is not called when DNS lookup fails

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: shawn <at> shenso.name, 78920 <at> debbugs.gnu.org
Subject: bug#78920: 30.1; Process sentinel is not called when DNS lookup fails
Date: Mon, 30 Jun 2025 16:36:24 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: shawn <at> shenso.name,  78920 <at> debbugs.gnu.org
> Date: Mon, 30 Jun 2025 15:12:48 +0200
> 
> >>>>> On Mon, 30 Jun 2025 15:52:45 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>     >> Eli, what can we do here? Whether or not Emacs is using getaddrinfo_a
>     >> should not affect the behaviour here, although having a process be
>     >> created is unavoidable, since weʼre deferring the DNS lookup.
> 
>     Eli> If we want the same behavior, we should signal an error when DNS look
>     Eli> up fails.
> 
> OK
> 
>     >> The docstring for `make-network-process' says this in the :nowait
>     >> section:
>     >> 
>     >> the sentinel function will be called with second arg matching
>     >> "open" (if successful) or "failed" when the connect completes.
>     >> 
>     >> Pedantically, the `connect' syscall is not completed, since we never
>     >> attempt it because of the DNS failure. But the "attempt to connect to
>     >> the remote host" has completed, unsuccessfully, so we should call the
>     >> sentinel (and not call it when the process is deleted).
> 
>     Eli> But then the behavior will not be like we get when getaddrinfo_a is
>     Eli> unavailable, no?
> 
> True. Then the semantics would be "we couldnʼt create a process
> because DNS failed" in both cases (and the sentinel is not called). I
> wonder if doing it the other way would be more in line with peopleʼs
> expectations:
> 
>     `make-network-process' with :nowait t always succeeds, and if thereʼs
>     a DNS failure the sentinel is called with an error.
> 
> After all, :nowait t is the caller asking for asynchronicity.
> 
> Either way, Emacsʼ behaviour changes.
> 
>     Eli> Technically, we have no process object in this case; the fact that we
>     Eli> create one is an implementation detail.  I'd even go as far as saying
>     Eli> that this "process" should not be exposed to Lisp.
> 
> Then weʼd need to split `make_process' between creating the C-level
> process object, and adding that object to `Vprocess_alist' (I hope
> that would be enough). And we have to expose it to Lisp in some form,
> since `make-network-process' returns a process object.

We could give the process a special attribute, and make Lisp APIs skip
it.

But maybe calling the sentinel will be easier and less drastic?  We
just need to document that the behavior is not identical to the
systems where async DNS resolution is unavailable.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.