[Openmcl-devel] Thread problem/question
gb at clozure.com
Fri Sep 8 03:14:16 UTC 2006
There's a general overview of how threads and special variables
I'm not sure if that'd be helpful in this case.
On Thu, 7 Sep 2006, Phil wrote:
> My latest (SLIME-related) problem is that I'm experiencing
> inconsistent behavior that I believe is related to threads and could
> use some advice on how to troubleshoot / what additional information
> I need to collect.
One obvious (in hindsight) question to ask is whether there are
different symbols named FOO in different packages. E.g., if
? (FIND-ALL-SYMBOLS "FOO")
returns a list containing more than one symbol, it's possible (maybe
likely) that different threads/buffers have different bindings of
*PACKAGE* and therefore the unqualified references to FOO refer
to different symbols.
If that doesn't explain what you're seeing, I'm not sure what would;
it sounds unlikely that dynamic binding is having any effect.
> In a nutshell, I've noticed on a number of occasions (in 1.0 as well
> as the latest 1.1 snapshot) where I would (re)define a function or
> variable on a separate thread (SLIME creates a new thread when a form
> is evaluated via c-x c-e in a non-REPL buffer such as editing a Lisp
> source file) but the REPL claims it is unbound and vice-versa when I
> define a variable in the REPL. At other times, things work as
> expected... although the behavior is always consistent for the
> duration of the session (i.e. if I quit the session and start over, I
> may experience different behavior)
> For example, I've got a session going right now where I have defined
> a variable via a source buffer but in the REPL, I'm told that foo is
> undefined. From the source buffer I execute:
> (setf foo "testing") => "testing"
> foo => "testing"
> (ccl::all-processes) => (#<PROCESS worker(74) [Active] #x920C896>
> #<PROCESS new-repl-thread(58) [semaphore wait] #x91E79A6> #<PROCESS
> reader-thread(7) [Active] #x91BD47E> #<PROCESS control-thread(6)
> [Active] #x91BD696> #<COCOA-LISTENER-PROCESS Listener(4) [Active]
> #x898E716> #<PROCESS Hemlock window thread(3) [semaphore wait]
> #x8990256> #<PROCESS housekeeping(2) [Active] #x8975BB6> #<PROCESS
> listener(1) [Active] #x83D3EF6> #<APPKIT-PROCESS Initial(0) [Active]
You could also try evaluating the form *PACKAGE* in a buffer and in
the REPL, to see if you get different results.
> Then from the repl, I execute:
> foo => Unbound variable: FOO
> (ccl::all-processes) => (#<PROCESS new-repl-thread(75) [Active]
> #x92014E6> #<PROCESS reader-thread(7) [Active] #x91BD47E> #<PROCESS
> control-thread(6) [Active] #x91BD696> #<COCOA-LISTENER-PROCESS
> Listener(4) [Active] #x898E716> #<PROCESS Hemlock window thread(3)
> [semaphore wait] #x8990256> #<PROCESS housekeeping(2) [Active]
> #x8975BB6> #<PROCESS listener(1) [Active] #x83D3EF6> #<APPKIT-PROCESS
> Initial(0) [Active] #x810B9FE>)
> Thinking that I might somehow be running multiple OpenMCL instances I
> checked via Activity Monitor and ps but they only show the single
> instance running.
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel