From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alain Schneble Newsgroups: gmane.emacs.devel Subject: Re: Asynchronous DNS Date: Tue, 9 Feb 2016 21:43:10 +0100 Message-ID: <864mdh8vj5.fsf@realize.ch> References: <83oabzzsjq.fsf@gnu.org> <87fuxazkfe.fsf@gnus.org> <83io25yeqk.fsf@gnu.org> <87h9hpnreg.fsf@gnus.org> <83y4b0wi7m.fsf@gnu.org> <87si17evk6.fsf@gnus.org> <83twlnvcz2.fsf@gnu.org> <87vb63obm3.fsf@gnus.org> <87r3gqmg6g.fsf@gnus.org> <83egcqtfnm.fsf@gnu.org> <86mvrdmk8p.fsf@realize.ch> <877fihjo4m.fsf@gnus.org> <86io20n3xn.fsf@realize.ch> <8760y055l1.fsf@gnus.org> <8660xzmyyr.fsf@realize.ch> <87pow7ocyw.fsf@gnus.org> <861t8nmxlj.fsf@realize.ch> <87y4auiurw.fsf@gnus.org> <86k2me8dee.fsf@realize.ch> <83a8n9ddk5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1455050652 23701 80.91.229.3 (9 Feb 2016 20:44:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Feb 2016 20:44:12 +0000 (UTC) Cc: larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 09 21:44:06 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aTF8o-0007ml-3T for ged-emacs-devel@m.gmane.org; Tue, 09 Feb 2016 21:44:06 +0100 Original-Received: from localhost ([::1]:60429 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTF8n-0003Qw-Ft for ged-emacs-devel@m.gmane.org; Tue, 09 Feb 2016 15:44:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTF8a-0003Qn-4C for emacs-devel@gnu.org; Tue, 09 Feb 2016 15:43:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTF8Z-0007z6-3I for emacs-devel@gnu.org; Tue, 09 Feb 2016 15:43:52 -0500 Original-Received: from clientmail.realize.ch ([46.140.89.53]:3369) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1aTF8T-0007yX-DS; Tue, 09 Feb 2016 15:43:45 -0500 Original-Received: from rintintin.hq.realize.ch.lan.rit ([192.168.0.105]) by clientmail.realize.ch ; Tue, 9 Feb 2016 21:43:24 +0100 Original-Received: from MYNGB (192.168.66.65) by rintintin.hq.realize.ch.lan.rit (192.168.0.105) with Microsoft SMTP Server (TLS) id 15.0.516.32; Tue, 9 Feb 2016 21:43:01 +0100 In-Reply-To: <83a8n9ddk5.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 09 Feb 2016 19:00:10 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (windows-nt) X-ClientProxiedBy: rintintin.hq.realize.ch.lan.rit (192.168.0.105) To rintintin.hq.realize.ch.lan.rit (192.168.0.105) X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] X-Received-From: 46.140.89.53 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:199633 Archived-At: Eli Zaretskii writes: >> `process-send-region', `process-send-string', `process-send-eof' >> >> Maybe the last three wouldn't be candidates as they throw an error even >> in the current implementation in case the process status is still >> 'connect, as you and I pointed out already in earlier notes. > > But if the wait is for the 'run' status, then it will fix those > problems as well (as I think we should). FWIW, I think I more and more tend to like this approach, where all those functions would block when called before the socket is connected -- incl. process-send-* functions that currently signal an error. Here is a quick (dump 'my 'humble 'mind) of what I think I learned from all of you so far in this thread and the arguments that make me feel more and more confident about this promising path: - We would get a very robust API that will DT(R)T, regardless of whether an async expert or a non-expert writes code against in. Both may fall into the blocking "trap". But those that care will certainly notice it. They will be the ones that read the documentation carefully, where it will cover this new async subtlety -- that functions accepting an async network process (made with :nowait t) and called before its state turned to "open" may block. - It will fix the inconsistency between process-send-* function and the others (such as set-process-coding-system), where the former today may signal errors while the latter do not. Having process-send-* functions block will certainly only fix issues and shall not introduce new ones. - Current (Lisp) API won't change at all. No need to extend :nowait. Current semantics of nil and t remain. We do not introduce any new idioms or configurations (e.g. that would be the case with 'immediate) that we might regret in the future. It should be fully backward compatible. - As it does not introduce any new concepts, it leaves the path open for extensions, should it turn out that a strict async programming model might be preferable over "the lax one" described above. We could still introduce things like this: (make-network-process ... :nowait 'strict-async :sentinel (lambda (p s) ( (await p) ... ))) ...where await /must/ be called in this 'strict-async mode. If p is used in a function (e.g. process-send-*) without having awaited it, all these functions would signal an error. So before any usage, one must await for p. If p's state is "open", then it's a no-op. If not, it would block until it is. Did I miss something? As said, besides the last point, this really is a summary of other's (Eli, Lars, Andreas) ideas and remarks. Thanks you, it's so interesting :)