From: Chetan Pandya <pandyacus@sbcglobal.net>
To: Miles Bader <miles@gnu.org>, Giuseppe Scrivano <gscrivano@gnu.org>
Cc: rms@gnu.org, emacs-devel@gnu.org
Subject: Re: multi-threaded Emacs
Date: Sun, 30 Nov 2008 16:10:53 -0800 (PST) [thread overview]
Message-ID: <502092.7273.qm@web83204.mail.mud.yahoo.com> (raw)
In-Reply-To: <87abbg7qvj.fsf@master.homenet>
--- On Sun, 11/30/08, Giuseppe Scrivano <gscrivano@gnu.org> wrote:
> From: Giuseppe Scrivano <gscrivano@gnu.org>
> Subject: Re: multi-threaded Emacs
> To: "Miles Bader" <miles@gnu.org>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Date: Sunday, November 30, 2008, 11:09 PM
> Miles Bader <miles@gnu.org> writes:
>
> > BTW, there was a huge thread maybe a year (?) or so
> ago about this subject.
> > Have you read it?
> >
> > IIRC, the basic consensus was that some sort of
> explicitly
> > non-preemptive threading was probably the best
> solution for emacs.
> >
> > -Miles
>
> I found a thread of 3 years ago (maybe is it this one?
> Time passes very
> fast :) ) but I didn't find any conclusion.
>
> Anyway, a non-preemptive threading will not give any real
> parallelism
> and it will require more changes in the Elisp packages to
> use threads as
> they will need to say explicitly when give the control to
> another
> thread.
> Instead `run-in-thread' will setup the call stack and
> finally give the
> control to the thread. The only change required in the
> Elisp packages
> to be used in a multithreaded environment is to protect
> global data
> accesses with a lock/unlock, but how many times does it
> happen to change
> the value of a global variable?
>
> Both solutions require changes in Elisp, a non-preemptive
> threading
> needs to explicitly yield the control to another thread,
> while having
> real threads needs to specify when access to global data
> must be
> protected. The latter one differently allows parallelism
> and I guess
> less changes in the Elisp code too (if writes to global
> data are less
> frequent than specify when exit from the current thread).
>
> Giuseppe
A non-preemptive threading model can also yield implicitly, but can have unexpected consequences - for example a global variable changing value between two uses within a function, or if two values that are modified together. In general, such transaction semantics have to be coded explicitly in a preemptive threading model, where as with a cooperative model, one has to be aware of only a few of such points.
Perhaps these things were discussed earlier. I will take a look.
Chetan
next prev parent reply other threads:[~2008-12-01 0:10 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-29 13:32 multi-threaded Emacs Giuseppe Scrivano
2008-11-29 20:26 ` Stefan Monnier
2008-11-29 21:01 ` Giuseppe Scrivano
2008-11-29 22:21 ` Stefan Monnier
2008-11-30 11:35 ` Giuseppe Scrivano
2008-11-30 21:46 ` Stefan Monnier
2008-11-30 22:25 ` Giuseppe Scrivano
2008-11-30 23:03 ` Stefan Monnier
2008-11-30 23:30 ` Giuseppe Scrivano
2008-12-01 3:37 ` Stefan Monnier
2008-12-06 22:50 ` Tom Tromey
2008-12-07 3:31 ` Stefan Monnier
2008-11-29 22:06 ` Tom Tromey
2008-11-30 16:43 ` Richard M Stallman
2008-11-30 17:34 ` Giuseppe Scrivano
2008-11-30 21:51 ` Stefan Monnier
2008-11-30 22:10 ` Giuseppe Scrivano
2008-11-30 22:20 ` Miles Bader
2008-11-30 23:09 ` Stefan Monnier
2008-11-30 23:09 ` Giuseppe Scrivano
2008-12-01 0:10 ` Chetan Pandya [this message]
2008-12-01 3:55 ` Stefan Monnier
2008-12-01 14:06 ` Richard M Stallman
2008-12-01 18:57 ` Giuseppe Scrivano
2008-12-01 20:34 ` Stefan Monnier
2008-12-01 22:41 ` joakim
2008-12-02 16:02 ` Richard M Stallman
2008-12-02 22:22 ` Stefan Monnier
2008-12-02 22:41 ` Giuseppe Scrivano
2008-12-03 2:17 ` Stefan Monnier
2008-12-03 18:26 ` Giuseppe Scrivano
2008-12-03 20:14 ` Stefan Monnier
2008-12-05 2:59 ` Richard M Stallman
2008-12-05 7:40 ` Giuseppe Scrivano
2008-12-05 8:20 ` Miles Bader
2008-12-05 9:42 ` Paul R
2008-12-05 10:10 ` Eli Zaretskii
2008-12-05 10:35 ` Paul R
2008-12-05 11:02 ` Helmut Eller
2008-12-05 15:39 ` Stefan Monnier
2008-12-05 16:22 ` Ted Zlatanov
2008-12-05 16:57 ` Tom Tromey
2008-12-06 4:41 ` Miles Bader
2008-12-06 7:44 ` Helmut Eller
2008-12-06 22:31 ` Stefan Monnier
2008-12-06 8:30 ` Richard M Stallman
2008-12-05 15:36 ` Stefan Monnier
2008-12-06 19:25 ` Richard M Stallman
2008-12-06 22:41 ` Stefan Monnier
2008-12-06 23:41 ` Giuseppe Scrivano
2008-12-07 20:51 ` Stefan Monnier
2008-12-07 23:51 ` Giuseppe Scrivano
2008-12-08 3:06 ` Chetan Pandya
2008-12-08 15:50 ` Stefan Monnier
2008-12-07 16:02 ` Richard M Stallman
2008-12-07 20:52 ` Stefan Monnier
2008-12-07 16:15 ` Giuseppe Scrivano
2008-12-08 18:26 ` Richard M Stallman
2008-12-08 19:49 ` Giuseppe Scrivano
2008-12-09 2:15 ` dhruva
2008-12-09 2:49 ` Stephen J. Turnbull
2008-12-09 2:53 ` dhruva
2008-12-09 9:36 ` Andreas Schwab
2008-12-09 17:26 ` Richard M Stallman
2008-12-09 19:10 ` Giuseppe Scrivano
2008-12-10 18:18 ` Richard M Stallman
2008-12-10 18:18 ` Richard M Stallman
2008-12-09 19:40 ` Stefan Monnier
2008-12-10 18:18 ` Richard M Stallman
2008-12-11 1:59 ` Stefan Monnier
2008-12-11 14:41 ` Ted Zlatanov
2008-12-11 18:30 ` Stefan Monnier
2008-12-11 18:42 ` Ted Zlatanov
2008-12-11 19:01 ` Paul R
2008-12-11 20:53 ` Stefan Monnier
2008-12-12 19:03 ` Giuseppe Scrivano
2008-12-13 3:08 ` Stefan Monnier
2008-12-11 19:07 ` Paul R
2008-12-11 20:54 ` Stefan Monnier
2008-12-05 2:59 ` Richard M Stallman
2008-12-05 15:40 ` Stefan Monnier
2008-12-02 23:10 ` Florian Beck
2008-11-30 22:17 ` Miles Bader
2008-11-30 16:44 ` Richard M Stallman
-- strict thread matches above, loose matches on Subject: below --
2008-12-03 7:59 Re[2]: " ak70
2008-12-04 8:45 ` Richard M Stallman
[not found] ` <87prk8mhg9.fsf@vanilla.net.mt>
[not found] ` <E1L8ZUB-0002x3-VT@fencepost.gnu.org>
2008-12-05 13:27 ` Li Lin
[not found] ` <87prk64ilv.fsf@vanilla.net.mt>
2008-12-05 18:37 ` Giuseppe Scrivano
2008-12-06 21:58 ` Magnus Henoch
2008-12-04 13:21 ` Stefan Monnier
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=502092.7273.qm@web83204.mail.mud.yahoo.com \
--to=pandyacus@sbcglobal.net \
--cc=emacs-devel@gnu.org \
--cc=gscrivano@gnu.org \
--cc=miles@gnu.org \
--cc=rms@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.