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

[Jack Unrue]

On 11/6/06, Nikodemus Siivola <nikodemus at random-state.net> wrote:
> "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.

The message loop works fine from a bare REPL in SBCL.

> > 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?

It does seem confusing, but that's indeed what I'm saying. Unfortunately,
the case where GetMessage returns is when I've hacked my code to the
extent that it's not actually entering the normal message loop -- and I
don't yet understand why, after subsequently restoring the calls to
GetMessage, that my message loop works. I can only speculate that
some kind of internal state in either swank or SBCL has been modified
by the initial "hacked up" run.

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

I will work on a test case that just uses SBCL's FFI and make that
available.

> 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.

I'd be happy to help test this.

Thanks for your response, and I'll provide a standalone test case
shortly.

-- 
Jack Unrue