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

Previous Next

Package: emacs;

Reported by: Shawn Henson <shawn <at> shenso.name>

Date: Sat, 28 Jun 2025 23:27:04 UTC

Severity: normal

Found in version 30.1

Full log


Message #38 received at 78920 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: shawn <at> shenso.name, 78920 <at> debbugs.gnu.org
Subject: Re: bug#78920: 30.1; Process sentinel is not called when DNS lookup
 fails
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.

Robert
-- 




This bug report was last modified 5 days ago.

Previous Next


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