[Openmcl-devel] thread overview

[Gary Byers]

On Sun, 22 Aug 2004, alex crain wrote:

> Could someone (gary?) post a summary of what all the various threads in
> mcl do and what the development strategy is for the future?

This isn't entirely nit-picking: MCL and OpenMCL are different environments
that behave differently (especially where threads are concerned.)

>
> For example: Mcl boots up with three threads, presumably a listener, a
> garbage collector and the main thread.

In the "tty world", OpenMCL starts out with 2 lisp-level threads:

? :proc
1 : -> listener     [Active]
0 :    Initial      [Active]

If you look at a running OpenMCL with a debugging tool (GDB or Apple's
Thread Viewer.app), you'll see an additional kernel-level thread on Darwin;
this is used by the Mach exception-handling mechanism.

The initial thread is the one that was created by the OS when the (OS)
process was created.  It maps the heap image into memory, does some
lisp-level initialization, and then (in the default TTY-based world)
creates a listener thread.  After the listener thread is created, the
initial thread does "housekeeping": it sits in a loop, sleeping most
of the time and waking up occasionally to do "periodic tasks".  These
tasks include forcing output on specified interactive streams, checking
for and handling ^C interrupts, etc.  Currently, those tasks also include
polling for the exit status of external processes and handling some
kinds of I/O to and from those processes.

In this environment, the initial thread does these "housekeeping" activities
until CCL:QUIT is called; QUITting interrupts the initial thread, asking
it to shutdown other threads in as orderly as fashion as possible and
then #_exit.

The short-term plan is to handle each external-process in a dedicated
thread; the worst-case behavior of the current scheme can involve
busy-waiting and excessive CPU utilization while waiting for an external
process to terminate in some cases.


> I get two more when I add a
> COCOA listener and two more for each COCOA editor window. I'm looking
> for insights into what types of tasks are delegated to existing threads
> as opposed to new threads, etc.

The Cocoa event loop has to run in the initial thread; when the event loop
starts up, it creates a new thread to do "housekeeping".

In the bleeding-edge Hemlock-based Cocoa, each editor window has a
dedicated thread associated with it; that thread is responsible for
receiving key events, trying to interpret them as Hemlock commands,
applying those commands to the active buffer, and repeating the
process until the window closes.  This thread-per-window scheme makes
many things simpler, including the process of entering a "recursive
command loop" in commands like "Incremental Search Forward", etc.  (It
might be possible to handle all Hemlock commands in the Cocoa event
thread, but these "recursive command loops" would have to maintain a
lot of context/state information; threads are a straightforward way of
maintaining that information.)  I think that the per-window thread
could probably take more responsibility for drawing/screen than it
currently does; -something- needs to be done to buffer screen updates
a bit better in some cases (you don't need to see everything that happens
during something like indentation; you do need to see the results ...)


Since listener windows are editor windows, you should see a lisp thread
that handles Hemlock command processing as well as the listener thread
associated with each listener window.  The Cocoa runtime may make additional
threads whenever it's in the mood to do so; these threads usually don't
run lisp code (and rarely if ever run much of it, currently.)


>
> :alex
>

You seem to be subscribed as "alexcrain at widgetworks.com"; I tried to make
the mailing list accept mail from "axexcrain at mail2.widgetworks.com" as
well.