unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Jonathan Rockway <jon@jrock.us>
To: Emacs Devel <emacs-devel@gnu.org>
Subject: Re: Very interesting analysis of "the state of Emacs"
Date: Wed, 30 Apr 2008 23:23:03 -0500	[thread overview]
Message-ID: <87bq3qodp4.fsf@bar.jrock.us> (raw)
In-Reply-To: <874p9jhsa7.fsf@localhorst.mine.nu> (David Hansen's message of "Thu, 01 May 2008 00:49:52 +0200")

* On Wed, Apr 30 2008, David Hansen wrote:
> There are some small languages that implement this (e.g. Lua or Scheme
> (not in the standard but it's a natural use for continuations)).  The
> main problem I would see is emacs dynamic scope, e.g. what's the value
> of a variable in one thread if another one let binds it.

I don't think let bindings are the problem, it's easy for two
invocations of the same function to have separate dynamic scopes.
Consider:

  (defun foo nil (let (a b c) (bar)))
  (defun bar nil (message "(a %s) (b %s) (c %s)" a b c))
 
If we start two foos in parallel, everything works:

  1:                          2:
  foo                         foo
  let #<scope (a, b, c) 0x1>  let #<scope (a, b, c) 0x2>
  bar (uses scope 0x1)        bar (uses scope 0x2)

Basically, each invocation is logically a separate process.  I don't see
any problems with something like this.  The dynamic scope is not a
show-stopper, anyway.

The issue is when we start putting global variables into the mix:

  (defvar shared 42)
  (defun foo nil (incf shared) (incf shared))
  (defun bar nil (decf shared))

If foo and bar start running at the same time, what does shared end up
being?  Without parallelism, you can guarantee that the output of bar
will always be < the initial value of shared.  But not anymore; if "foo"
happens to run while "bar" is running, that's no longer true.

This is a bad example, but this sort of thing is a big problem.  Perhaps
it can be handled by giving each "thread" a copy of the global VM state.

But of course... what do you do for things that can't be copied, like
buffers or window layouts?  What happens if something like this
executes in parallel:

   A (some-slow-function) (goto-char 42)
   B (save-excursion (goto-char 0) (do-something))

And the execution order happens to be:

  (goto-char 1234)
  A (some-slow-function)
  B (save-excursion (goto-char 0)
  A (goto-char 42)
  B (do-something)
  B )

Where is the point now?  Logically it would be at 42, since the
save-excursion shouldn't have moved it... but the save-excursion sets it
back to the initial value of 1234 when it unwinds.  This makes sense
when you look at the execution order, but that's non-deterministic so it
will never be consistent.

Anyway, hopefully someone has some ideas on what to do here.  I admit I
haven't looked at how sxemacs handles this yet. Maybe we can just deal
with locks?  At least in that case my IMAP mail could download while I
am typing in another buffer :)

Regards,
Jonathan Rockway

-- 
print just => another => perl => hacker => if $,=$"




  parent reply	other threads:[~2008-05-01  4:23 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-29  3:19 Very interesting analysis of "the state of Emacs" Thomas Lord
2008-04-29  7:26 ` Paul Michael Reilly
2008-04-29 23:17   ` Richard M Stallman
2008-04-30  0:14     ` Thomas Lord
2008-04-30  2:21     ` Stephen Eilert
2008-04-30  3:20       ` dhruva
2008-04-30 22:00         ` Richard M Stallman
2008-04-30 22:49           ` David Hansen
2008-04-30 23:46             ` Thomas Lord
2008-05-01  7:30               ` tomas
2008-05-01  4:23             ` Jonathan Rockway [this message]
2008-05-01  6:31               ` David Hansen
2008-05-01  6:42               ` Miles Bader
2008-05-01 18:59                 ` Jonathan Rockway
2008-05-02 15:36                 ` Stefan Monnier
2008-05-02 16:50                   ` CEDET and threads (was Re: Very interesting analysis of "the state of Emacs") Eric M. Ludlam
2008-05-03  8:09                   ` Very interesting analysis of "the state of Emacs" Richard M Stallman
2008-05-03 19:24                     ` Stefan Monnier
2008-05-04  9:37                       ` Richard M Stallman
2008-05-04 23:23                         ` buffer transactions (was Re: Very interesting analysis of "the state of Emacs") Nic
2008-05-05 15:14                           ` Richard M Stallman
2008-04-30  5:12       ` Very interesting analysis of "the state of Emacs" Miles Bader
2008-04-30 14:06         ` David Kastrup
2008-04-30 15:08         ` Tom Tromey
2008-05-15  6:21           ` ERC disconnects when blocked too long (was: Very interesting analysis of "the state of Emacs") Michael Olson
2008-04-30 16:08         ` Very interesting analysis of "the state of Emacs" Thomas Lord
2008-04-30  6:24       ` Paul Michael Reilly
2008-04-30 14:12       ` Mathias Dahl
2008-04-30 22:01       ` Richard M Stallman
2008-04-30 22:56         ` Thomas Lord

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=87bq3qodp4.fsf@bar.jrock.us \
    --to=jon@jrock.us \
    --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).