From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Crash recovery strategies Date: Sun, 3 Jan 2016 15:51:13 -0800 Message-ID: <5689B3F1.6010201@dancol.org> References: <83mvu1x6t3.fsf@gnu.org> <56797CD9.8010706@cs.ucla.edu> <8337uuqsux.fsf@gnu.org> <5679DC83.70405@cs.ucla.edu> <83oadhp2mj.fsf@gnu.org> <567AD556.6020202@cs.ucla.edu> <567AD766.3060608@dancol.org> <567B5DAB.2000900@cs.ucla.edu> <83fuyromig.fsf@gnu.org> <567C25B1.3020101@dancol.org> <56892FD6.8040708@dancol.org> <568988EE.3010205@dancol.org> <56899278.9000007@dancol.org> <56899EAC.1030408@dancol.org> <5689A6DE.2080709@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3i3ARB3QhmeFRmnGCDVJKT5g6hdDQC2dB" X-Trace: ger.gmane.org 1451865109 17679 80.91.229.3 (3 Jan 2016 23:51:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 23:51:49 +0000 (UTC) To: Eli Zaretskii , Paul Eggert , Emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 04 00:51:41 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 1aFsR3-0003GJ-55 for ged-emacs-devel@m.gmane.org; Mon, 04 Jan 2016 00:51:41 +0100 Original-Received: from localhost ([::1]:43272 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFsQz-0002nO-AG for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 18:51:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44175) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFsQn-0002nI-1C for Emacs-devel@gnu.org; Sun, 03 Jan 2016 18:51:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFsQj-0003m5-RD for Emacs-devel@gnu.org; Sun, 03 Jan 2016 18:51:24 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:40839) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFsQj-0003m1-KP; Sun, 03 Jan 2016 18:51:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=iXTYrIXlMKwIB1qUB/6YjODFChQbc7jZIDnkt6CWc8Q=; b=izHYX7Vu7WzbeNAFokNUin9YfgOarNd8LjMG54haW1kYt4XPHcEm20hdAWRV9AqFxaPJpeNTSoh0/LodBo4ymwd3Iyh/NSb04EecIqlcVjxMARHKvmFqXzu6lCek4H9VzqgfLG7a97sG2cjY/MxkIZheGh60IaPSkCWLJXQAsNGHiUp4/HrmRvUpuUMwxiWzSQTekwZs2j4gOi6nCZ2JZKWB6GevK6VVGZgJQbUJm5ZHz0rLIgMpy+h/9mNeQkeaHlbWCfjZcgUe/uUva/rbXuoTLuDnyNJ4IkLRV8R+W1opo/DAKNB7G8FgHrleGfJB72cXHPGWyEB3Hszw+MfCzg==; Original-Received: from mobile-166-176-184-191.mycingular.net ([166.176.184.191] helo=[192.168.43.34]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aFsQj-000888-11; Sun, 03 Jan 2016 15:51:21 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:197535 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3i3ARB3QhmeFRmnGCDVJKT5g6hdDQC2dB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/03/2016 03:47 PM, John Wiegley wrote: >>>>>> Daniel Colascione writes: >=20 >> If implementing a scheme like this is what it takes to kill the stack >> overflow code, I think I can implement it. >=20 > Even if we don't kill the stack overflow code, would you be interested = in > trying out your async spawn idea? That might have other useful applicat= ions > too. In fact, I've wanted to move async.el's ideas into the C level for= a > while (to avoid text-based marshalling between parent and child Emacsen= ), and > this could dovetail beautifully with that desire... How would moving to C help? Keep in mind that we're talking about fork *and exec*, so the parent and child don't share memory. They can, however, communicate over a pipe. Lisp already has read and print, so given the choice, I'd rather implement cross-process functionality in Lisp. Sure, that's text-based marshaling, but with it's general, isn't it= ? They only difficulty I have in mind is making sure that the child Emacs can display UI to the user, which involves matching window-system parameters like DISPLAY. That said, if we do end up implementing async-spawn, and we need to be able to do it from C *anyway*, we can certainly expose that C functionality to regular Lisp callers. --3i3ARB3QhmeFRmnGCDVJKT5g6hdDQC2dB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWibPxAAoJEN4WImmbpWBlZfkP/1ogVX1FqYnLTpaaW0xoN9bL X7bd2SSuzutv4KHXkQobARv6WgP7rgAuT+z03YOZuwzYTlDIB1EZp6n3seMt/eLN J6sxhGiIv7fuwzFfEIpDwIcjnHX0eczKAEpW9/TM0t8goBPK/tGlZJvPaCcT9/F+ 4JBsVJYupkV1jZhiijxC/6w42pnI2d8VQVJytdP0XGgbSXckh54ymY6FZVU9as2E aXwDh1uti7ny05pmn8CB20xMmLhAmMVVHjRr37g497LiMuewjVxjTy7faWFGaUdR h96blrpyzx+g6MRbyKimS/BEnmlzUEDEk+W4tsL2vPdHtW+0UyfEEUWJoBFmDQqX 5dXDT5fLJjsxjeTpDkMQPwA3q5KR/O/XqDd7ziqEPNxRwMPUVZ59ARi7myr8FQfe VpJRWu+DZPoTCif0koZ2AgfveFaq3zYEWeblvywIVuMLaNipzddWB/tNkdkRM8I5 xejSwIA4dia+7QKubv6WZYJz4uZ7j+5TFUqrXRL1UtvYOofp5RMyKWuBzGefr90J u9+vyPIf5M1rnEt2c4OPcaD5hQcGASyuX7S7ypXg8NMQjOIz6j/B+8s6Jst44wfI kfabPEyhWUPXnWLDCojj45tjCe+dvYv7GxBUUAQgsFrr1agUOPciRPRDgYJV8+2T HZQmpHTJE/eZebOQVB+t =Ykqc -----END PGP SIGNATURE----- --3i3ARB3QhmeFRmnGCDVJKT5g6hdDQC2dB--