unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: emacs-devel@gnu.org
Subject: Re: Make computational threads leave user interface usable
Date: Fri, 03 Nov 2017 11:50:46 -0400	[thread overview]
Message-ID: <jwvmv43fk0d.fsf-monnier+gmane.emacs.devel@gnu.org> (raw)
In-Reply-To: CAG7BpapO_vyX-v+8tSg7r9q60MHSdvZU+GY5Me26LZrRxYB95A@mail.gmail.com

> What if this auto-yield is made optional?

The problem is that the megabytes of C and Lisp code out there all
assume that there's only a single thread running.  This assumption is so
strong that we don't even really provide the synchronization primitives
necessary to make real concurrent programming usable (e.g. locks,
transactions, ...).

So such an option would be similar to a "please corrupt my Emacs state
in random ways" option.

As you've seen context switches are currently very expensive (they
undo all the dynamic-bindings of the source thread and reinstall the 
dynamic-bindings of the destination thread).

It's probably a good idea to start thinking about how to add real
concurrency to Emacs, but it needs to start by looking at how we can
make sure the concurrent threads only share read-only data (plus some
extra shared state properly protected via some transactional system, or
maybe just no shared state but some messaging mechanism instead).

That requires a serious design effort on the Elisp side, with a good
understanding of the current C code, plus some deep changes at the
C level.


        Stefan




  parent reply	other threads:[~2017-11-03 15:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01 15:06 Make computational threads leave user interface usable Paul Pogonyshev
2017-11-01 15:10 ` Paul Pogonyshev
2017-11-01 18:12 ` John Wiegley
2017-11-01 20:03   ` Eli Zaretskii
2017-11-01 21:19   ` Paul Pogonyshev
2017-11-01 21:47     ` John Wiegley
2017-11-03 15:50     ` Stefan Monnier [this message]
2017-11-01 19:10 ` Noam Postavsky
2017-11-01 20:16   ` Eli Zaretskii
2017-11-01 20:26     ` Noam Postavsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvmv43fk0d.fsf-monnier+gmane.emacs.devel@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).