[slime-devel] Re: Partial multiprocessing support on CMUCL

[Luke Gorrie]

Luke Gorrie <luke at bluetail.com> writes:

> Peter Siebel suggests using monitors. Now that I think about it, I
> have already defined (SUSPEND-THIS-THREAD) and (RESUME THREAD)
> primitives, which would be enough to build monitors with. Maybe that
> is the way to go.

I asked some guys at work how to do this. It turns out that mutexes
are enough, and it can be done without those SUSPEND/RESUME primitives
or monitors. "Bread and butter POSIX threads stuff."

The algorithm is this:

  We define a global lock L, and a global variable WHO that is bound
  to the thread currently allowed to talk to Emacs.

  Every thread that wants to talk to Emacs loops:
    Acquire lock L:
      If I am WHO, do my processing.
    Release L

  The Swank thread's "processing" is to read and evaluate a command
  from Emacs, and then loop. That command may have the side-effect of
  reassigning WHO to another thread.

  The "processing" of all other threads is to conduct a conversation
  with Emacs and then reassign WHO back to the Swank thread.

When a thread wants to be debugged, it goes until a loop waiting
until it becomes WHO. When Emacs chooses to debug such a thread, it
tells the Swank thread to assign WHO accordingly. When that thread
finishes debugging, it reassigns WHO to the Swank thread.

I'll implement this tomorrow unless a better way comes along.

Cheers,
Luke