From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Missing sentinel events Date: Sun, 22 Jan 2017 18:09:40 +0100 Organization: Programmerer Ingebrigtsen Message-ID: <8737gbm36z.fsf@gnus.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1485105022 7779 195.159.176.226 (22 Jan 2017 17:10:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 22 Jan 2017 17:10:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 22 18:10:18 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cVLef-0001Dp-To for ged-emacs-devel@m.gmane.org; Sun, 22 Jan 2017 18:10:14 +0100 Original-Received: from localhost ([::1]:37133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVLej-0005Ib-G4 for ged-emacs-devel@m.gmane.org; Sun, 22 Jan 2017 12:10:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVLeV-0005DQ-SG for emacs-devel@gnu.org; Sun, 22 Jan 2017 12:10:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cVLeR-0005ZF-NQ for emacs-devel@gnu.org; Sun, 22 Jan 2017 12:10:03 -0500 Original-Received: from [195.159.176.226] (port=36741 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cVLeR-0005Yu-GU for emacs-devel@gnu.org; Sun, 22 Jan 2017 12:09:59 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cVLeH-0007eT-8P for emacs-devel@gnu.org; Sun, 22 Jan 2017 18:09:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 74 Original-X-Complaints-To: usenet@blaine.gmane.org Mail-Copies-To: never Cancel-Lock: sha1:xf97y9cKdadxHd5MEzv2IWqNcRI= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:211537 Archived-At: While looking at all the failure modes, we seem to be lacking a few during async connection. The manual says that sentinels get codes like: ----- The string describing the event looks like one of the following: "finished\n". "deleted\n". "exited abnormally with code exitcode (core dumped)\n". The “core dumped” part is optional, and only appears if the process dumped core. "failed with code fail-code\n". [many more removed here] --- But this is the code from process.c: else if (p->outfd < 0) { /* The counterparty may have closed the connection (especially if the NSM prompt above take a long time), so recheck the file descriptor here. */ pset_status (p, Qfailed); deactivate_process (proc); } else if ((fd_callback_info[p->outfd].flags & NON_BLOCKING_CONNECT_FD) == 0) { /* If we cleared the connection wait mask before we did the TLS setup, then we have to say that the process is finally "open" here. */ pset_status (p, Qrun); /* Execute the sentinel here. If we had relied on status_notify to do it later, it will read input from the process before calling the sentinel. */ exec_sentinel (proc, build_string ("open\n")); } I suspect that I just forgot to put those calls to exec_sentinel into the "fail" bits here and other places in the code when I rewrote these parts last February, like this: /* The DNS lookup failed. */ else if (connecting_status (p->status)) { deactivate_process (proc); pset_status (p, (list2 (Qfailed, concat3 (build_string ("Name lookup of "), build_string (p->dns_request->ar_name), build_string (" failed"))))); } Doesn't it seem like these should be calling the sentinel, too? I think so, but there's a slight chance that adding more sentinel calls will break some user-level code that's not expecting to see any new messages... And the manual says "looks like one of the following", and people may have interpreted that as an exhaustive list of event strings. Any thoughts? It's incomplete as it is now, so we should definitely add more sentinel calls, but should they all look like "failed with code fail-code\n" or should they be... more meaningful? I think perhaps I should just add "more meaningful" sentinel messages, and if it turns out to be a problem in real life, we can change them all to "failed with code" messages... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no