emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concurrency


From: Tom Tromey
Subject: Re: Concurrency
Date: Mon, 29 Mar 2010 10:58:05 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

>>>>> "Ken" == Ken Raeburn <address@hidden> writes:

Tom> I think it would be better to have all mutexes be recursive, because it
Tom> is safer.

Ken> I can see some desire for recursive mutexes, but I lean towards
Ken> Butenhof's view myself.

I realized later I should probably expand on this.

The issue I have with non-recursive mutexes has to do with the nature of
Emacs itself.  First, there is a large body of existing elisp that we
don't want to break.  And, second, Emacs changes over time and it is
very common to write backward compatibility hacks and the like to make
elisp work with multiple versions.  Finally, Emacs is not and will never
be a high-performance environment.

I think these issues imply that we should pick the safe option always.

As a concrete example, consider the one existing user-visible mutex in
Emacs right now: the minibuffer mutex.  Lots of code, like yes-or-no-p,
acquires and releases this mutex.

But suppose you want to write a function that uses the minibuffer for a
multi-step operation, and you want to use yes-or-no-p (or something
else) as a subroutine.

If you have recursive mutexes, no problem, just acquire the lock.

If you don't have recursive mutexes, then all the primitives must be
duplicated into -lock and -nolock variants; or, the primitives should do
no locking and must be called with the lock held.

I'm not a fan of the first option, since it means an explosion of
functions.  And the second option is also bad, because it breaks
existing elisp.

(FWIW I am not sure a minibuffer mutex is the right thing.  It seems
like this should be at least per-terminal.)

Ken> If all mutexes are recursive, I'd like a
Ken> way to find out if I've already got a mutex locked, so I can
Ken> manually detect when I've screwed up my locking model, even if
Ken> someone else wants to use recursive mutexes in their code.

Ken> BTW, one extension I'd suggest is an optional timeout for
Ken> mutex-lock

These make sense to me.

Tom




reply via email to

[Prev in Thread] Current Thread [Next in Thread]