From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: Non-blocking open-network-stream Date: 26 Feb 2002 23:46:32 +0100 Message-ID: References: <5xwux64cxe.fsf@kfs2.cua.dk> <5xg03pyyo3.fsf@kfs2.cua.dk> Reply-To: Helmut Eller NNTP-Posting-Host: quimby2.netfonds.no X-Trace: quimby2.netfonds.no 1014763978 30914 195.204.10.66 (26 Feb 2002 22:52:58 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 26 Feb 2002 22:52:58 GMT Cc: emacs-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16fqSw-00082W-00 for ; Tue, 26 Feb 2002 23:52:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16fqPQ-0003lO-00; Tue, 26 Feb 2002 17:49:20 -0500 Original-Received: from [212.186.11.228] (helo=xaital.online-marketwatch.com) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16fqMq-0003af-00 for ; Tue, 26 Feb 2002 17:46:40 -0500 Original-Received: (from helmut@localhost) by xaital.online-marketwatch.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id XAA25200; Tue, 26 Feb 2002 23:46:33 +0100 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: storm@cua.dk's message of "25 Feb 2002 23:38:52 +0100" Original-Lines: 59 X-Mailer: Gnus v5.7/Emacs 20.7 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: quimby.gnus.org gmane.emacs.devel:1565 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1565 storm@cua.dk (Kim F. Storm) writes: > Here is my second attempt at a patch to support non-blocking > open-network-stream. I think the problem I described last time is still present. The problem is that the filter is invoked before the sentinel. This happens when the stream is readable immediately after the transition from connect state to open state. Consider wait_reading_process_input: > --- 3001,3047 ---- [...] > + XSETINT (p->tick, ++process_tick); > + if (getpeername(channel, &pname, &pnamelen) < 0) [...] > + else > + { > + p->status = Qrun; Tick is incremented and status is set to Qrun. Incrementing tick causes status_notify to be invoked during the next iteration. But status_notify ... > --- 4624,4630 ---- [...] > while (! EQ (p->filter, Qt) > + && ! EQ (p->status, Qconnect) > && XINT (p->infd) >= 0 > && read_process_output (proc, XINT (p->infd)) > 0); ... calls read_process_output (and the filter) before the sentinel. A simple solution is to call the sentinel in wait_reading_process_input without incrementing tick, e.g.: --- 3001,3047 ---- ... + if (getpeername(channel, &pname, &pnamelen) < 0) + XSETINT (p->tick, ++process_tick); ... + else + { + p->status = Qrun; + exec_sentinel (proc, Qopen); Another point: is it a problem to pass the error message and not just the error number to the sentinel? Helmut. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel