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