From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Missing sentinel events Date: Sun, 22 Jan 2017 19:42:58 +0200 Message-ID: <83tw8r3s9p.fsf@gnu.org> References: <8737gbm36z.fsf@gnus.org> Reply-To: Eli Zaretskii 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 1485107022 7291 195.159.176.226 (22 Jan 2017 17:43:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 22 Jan 2017 17:43:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 22 18:43:38 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 1cVMAZ-0007sh-HA for ged-emacs-devel@m.gmane.org; Sun, 22 Jan 2017 18:43:11 +0100 Original-Received: from localhost ([::1]:37226 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVMAe-0004Gl-OI for ged-emacs-devel@m.gmane.org; Sun, 22 Jan 2017 12:43:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVMAX-0004Ge-J1 for emacs-devel@gnu.org; Sun, 22 Jan 2017 12:43:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cVMAT-0007EB-3J for emacs-devel@gnu.org; Sun, 22 Jan 2017 12:43:09 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVMAS-0007E6-W9; Sun, 22 Jan 2017 12:43:05 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3911 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cVMAR-0004lQ-Kw; Sun, 22 Jan 2017 12:43:04 -0500 In-reply-to: <8737gbm36z.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 22 Jan 2017 18:09:40 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:211542 Archived-At: > From: Lars Ingebrigtsen > Date: Sun, 22 Jan 2017 18:09:40 +0100 > > 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. The list is exhaustive, so that interpretation is correct. You are looking at the error symbol that is put into the process status, but that's not what the sentinel will see. It will see what status_message will produce given the symbol. So you really must look at status_message and the strings it produces to see whether the list in the manual is exhaustive or not. > 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? What more meaningful messages did you have in mind? It's hard to reason in the abstract.