From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Non-blocking open-network-stream Date: 27 Feb 2002 12:59:04 +0100 Message-ID: <5xadtvuodz.fsf@kfs2.cua.dk> References: <5xwux64cxe.fsf@kfs2.cua.dk> <5xg03pyyo3.fsf@kfs2.cua.dk> NNTP-Posting-Host: quimby2.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: quimby2.netfonds.no 1014811462 30254 195.204.10.66 (27 Feb 2002 12:04:22 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 27 Feb 2002 12:04:22 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 16g2oo-0007rr-00 for ; Wed, 27 Feb 2002 13:04:22 +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 16g2kw-0003fZ-00; Wed, 27 Feb 2002 07:00:22 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.33 #1 (Debian)) id 16g2ie-0003Xk-00 for ; Wed, 27 Feb 2002 06:58:00 -0500 Original-Received: from kfs2.cua.dk.cua.dk (kfs2.local.filanet.dk [192.168.1.182]) by mail.filanet.dk (Postfix) with SMTP id 668E37C035; Wed, 27 Feb 2002 11:57:58 +0000 (GMT) Original-To: Helmut Eller In-Reply-To: Original-Lines: 36 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 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:1594 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1594 Helmut Eller writes: > 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. I've made the chage you suggested. Thanks. There is a general problem with handling a request for non-blocking connect on systems which does not support this. As I have specified this now, open-network-stream will proceed to emulate a non-blocking connect -- which means that it will block. And when the connect completes, it continues to pretend that the connect was non-blocking, so it setup the sentinel to be called after return, and all that jazz. I think it would be much cleaner if (open-network-stream ... t) simply returns nil if it doesn't support non-blocking connect. Then the code can do some smarter things (like delaying the connect), and I don't have to mess up the C code with all sorts of hacks to delay the delivery of a "failed to connect" message on a process which would not otherwise have to exist. Does this sound acceptable (since there is currently no code supporting non-blocking connect, this cannot break anything :-) -- Kim F. Storm http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel