From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Sun, 09 Oct 2016 13:13:08 +0000 Message-ID: References: <87wq97i78i.fsf@earlgrey.lan> <86k2dk77w6.fsf@molnjunk.nocrew.org> <9D64B8EA-DB52-413D-AE6A-264416C391F3@iotcl.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bd8fdfa382b4e053e6e685b X-Trace: blaine.gmane.org 1476018856 20128 195.159.176.226 (9 Oct 2016 13:14:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 9 Oct 2016 13:14:16 +0000 (UTC) Cc: Lars Brinkhoff , John Wiegley , emacs-devel@gnu.org To: =?UTF-8?B?U8O4cmVuIFBpbGfDpXJk?= , Toon Claes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 09 15:14:09 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btDvR-0003EK-P5 for ged-emacs-devel@m.gmane.org; Sun, 09 Oct 2016 15:13:57 +0200 Original-Received: from localhost ([::1]:44467 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btDvP-0004N9-UY for ged-emacs-devel@m.gmane.org; Sun, 09 Oct 2016 09:13:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btDus-0004Lr-2F for emacs-devel@gnu.org; Sun, 09 Oct 2016 09:13:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btDuq-00078l-VK for emacs-devel@gnu.org; Sun, 09 Oct 2016 09:13:21 -0400 Original-Received: from mail-lf0-x231.google.com ([2a00:1450:4010:c07::231]:33589) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btDuq-00078K-J3 for emacs-devel@gnu.org; Sun, 09 Oct 2016 09:13:20 -0400 Original-Received: by mail-lf0-x231.google.com with SMTP id x79so75195603lff.0 for ; Sun, 09 Oct 2016 06:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GWA8GmkPRNeoXZHPw0zQnc0LeUuUQaIo5VTDgExYAjk=; b=K3Y6y5iAmHQV1DVeYjcK/IHGuFV+NFm8qFJn9ceZzmWYznaypUFd3pprIw6Tw8wDUD lqJo7FXqFI8x2vT8i1/uYRY7gU6g0boLB67ngp9zL455fgtznCsOwzvVLGtIymRLNqfZ 78U9wYF2sLQZJcVZNvnOjKnsPegCd1BJGkhENcqP+n8TX3Xks+QtBvhD9QQLCf+cDrli Rtl74iP7iEJUs4tdzAkGa0ahVgc/mWHZGKPyBVqSGfF26jWTSPHqFuCaFK//hmMCWacc ydVDPlTpCql72aU7X8U3hW+PzHLFGfwKyuRTz4+z1B9XF8noYquhVhaguUrYiN+p/9i/ mjdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GWA8GmkPRNeoXZHPw0zQnc0LeUuUQaIo5VTDgExYAjk=; b=YmG2UvYkK0q8mafQmTviBL3RppOjxrS8wj4a7Xmve5tPuK17zF5a8CFqS0MGPEQ+O7 SbKLsJdT9lG+CCgGcdPnjYg5m5EipJAzwTNDhHeChJELhzeUISdOPBQ7eIYPW6yrN6gJ 7atAWKIAHH6KYbshqtFnysOegNntZQTnOSIkEclmuel5/fVl2NoPyk4XT4zUIVDB5GuB rSd7mvEjEupQB31R98kcM7bgepp27kkcA0jGxgQelQqCQH5uEqY7kBQW6Tsbyencfotw CCFrYPfL5czzOCEswp2fHOOmZI1FtUTczHEMNbUFSrn/fFi9EKiRQm/qc4e/V8HbUk5N PRuw== X-Gm-Message-State: AA6/9Rm2xH8n/isYQR+a1Ur+d2Oq4x6tmcb/muPsEpVwMh/tHaOUH3j71U0GgdDHsx3AVvXqsWL9Ul8cYyfk9g== X-Received: by 10.194.90.174 with SMTP id bx14mr24371202wjb.41.1476018799387; Sun, 09 Oct 2016 06:13:19 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::231 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:208117 Archived-At: --047d7bd8fdfa382b4e053e6e685b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable S=C3=B8ren Pilg=C3=A5rd schrieb am So., 9. Okt. 2016= um 14:44 Uhr: > On Sun, Oct 9, 2016 at 2:03 PM, Toon Claes wrote: > > > As you can see, introducing concurrency has wide implications for Emacs. > > Finding a way to go about it that will still allow old "naive" code to > > function correctly is what makes it so tough. > > Hopefully we will someday have that, but it requires a lot of hard work. > > Maybe we could start out with something like javascripts webworkers. A > > function running in its own world without access to buffers or other > > shared state, and then we could communicate by message passing. > Yes, this is the right approach. It is clear that new threads couldn't be allowed to access existing global state (dynamic variables, buffers, obarray, ...); instead they would need to start with an empty global state. > > But as the keen eye would observe that is very similar to simply > > spawning an external process. > > And it wouldn't benefit much for problems that rely on buffers or global > state. > > > That is a good thing; code should not use global state. Threads should have a properly synchronized method of communicating with each other (e.g. CSP-style channels), but shouldn't be able to access each other's state. --047d7bd8fdfa382b4e053e6e685b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


S=C3= =B8ren Pilg=C3=A5rd <fiskomaten@= gmail.com> schrieb am So., 9. Okt. 2016 um 14:44=C2=A0Uhr:
=
On Sun, Oct 9, 2016 at 2:03 PM, Toon Claes &= lt;= toon@iotcl.com> wrote:


As you can see, introducing concurrency has wide implications for Ema= cs.

Finding a way to go about it that will still= allow old "naive" code to

function co= rrectly is what makes it so tough.

Hopefully we = will someday have that, but it requires a lot of hard work.

Maybe we could start out with something like javascripts webwor= kers. A

function running in its own world withou= t access to buffers or other

shared state, and t= hen we could communicate by message passing.


Yes, this is the right approach. I= t is clear that new threads couldn't be allowed to access existing glob= al state (dynamic variables, buffers, obarray, ...); instead they would nee= d to start with an empty global state.
=C2=A0

But as the keen eye would observe that is very similar= to simply

spawning an external process.

And it wouldn't benefit much for problems that rely= on buffers or global state.



That is a good thing; code should not use global state. T= hreads should have a properly synchronized method of communicating with eac= h other (e.g. CSP-style channels), but shouldn't be able to access each= other's state.
--047d7bd8fdfa382b4e053e6e685b--