From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Asynchronous DNS Date: Tue, 09 Feb 2016 22:48:23 +0200 Message-ID: <83fux1bofc.fsf@gnu.org> 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> <864mdh8vj5.fsf@realize.ch> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1455050945 28852 80.91.229.3 (9 Feb 2016 20:49:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Feb 2016 20:49:05 +0000 (UTC) Cc: larsi@gnus.org, emacs-devel@gnu.org To: Alain Schneble Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 09 21:49:00 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 1aTFDY-0004Hf-EL for ged-emacs-devel@m.gmane.org; Tue, 09 Feb 2016 21:49:00 +0100 Original-Received: from localhost ([::1]:60461 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTFDX-0005ut-Tl for ged-emacs-devel@m.gmane.org; Tue, 09 Feb 2016 15:48:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38234) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTFDH-0005tm-Dk for emacs-devel@gnu.org; Tue, 09 Feb 2016 15:48:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTFDC-0000XK-E1 for emacs-devel@gnu.org; Tue, 09 Feb 2016 15:48:43 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48194) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTFDC-0000XF-A0; Tue, 09 Feb 2016 15:48:38 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1912 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aTFD9-00052H-Rh; Tue, 09 Feb 2016 15:48:37 -0500 In-reply-to: <864mdh8vj5.fsf@realize.ch> (message from Alain Schneble on Tue, 9 Feb 2016 21:43:10 +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.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:199634 Archived-At: > From: Alain Schneble > Date: Tue, 9 Feb 2016 21:43:10 +0100 > Cc: larsi@gnus.org, emacs-devel@gnu.org > > - 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 > :) Thanks for a nice summary. I don't think you missed anything.