[slime-devel] Re: single-threaded swank backend and message loops

Nikodemus Siivola nikodemus at random-state.net
Mon Nov 6 10:31:54 UTC 2006


"Jack Unrue" <jdunrue at gmail.com> writes:

> When I run sbcl via slime, not only does the slime repl freeze
> (which I accept as expected behavior), but the blocking call to
> get-message never returns either. I can use C-c C-c to interrupt
> sbcl, though.

The first order of business is to see if the happens without Slime. If
yes, we should probably take this to sbcl-devel...

Even if Slime is a required component, this does sound like an SBCL
issue, though.

> With some experimental hackery, which I have not yet boiled down to
> a workable solution, I can actually get a functional message loop
> running in the slime/sbcl case. This involves bastardizing my code's
> setup for the loop one time, let that execute and so it immediately
> returns control to slime, and then restore the correct code. So
> there seems to be a possibility of achieving the same behavior as
> I'm getting with clisp.

I'm not sure I understand. On one hand you say that your loop hangs in
GetMessage, which never returns, on the other you say that sometimes
it doesn't hang?

Can you send a test-case & example? (Depending on eg. GRAPHIC-FORMS is
OK, though a self-contained test-case would be nicer.)

A couple of not-directly applicable, but still related, things: 

* On Windows SBCL currently converts between FDs and HANDLEs in a way
  that is liable to cause trouble sooner or later. I would not be
  overly surprised if you troubles are mysteriously related to this. I
  have an slightly mutant (and right now defunct) tree that uses
  HANDLEs only, but there is still more work to be done there before
  it is good to go.

* In the long run SBCL will likely provide a wrapper on
  MsgWaitForMultipleObjects, so you can structure your loop something
  like

   (loop (process-message (sb-windows:get-message :serve-events t)))

  where SB-WINDOWS:GET-MESSAGE also deals with IO events from eg.
  Slime, dispatching them to the appropriate handlers. Since things
  like GRAPHIC-FORMS are probably among the primary users of such
  interfaces, your input on this would be good to have.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."




More information about the slime-devel mailing list