[Openmcl-devel] Thread problem/question

[Gary Byers]

There's a general overview of how threads and special variables
interact in

<http://clozure.com/mailman/htdig/openmcl-devel/2005-January/002374.html>

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]
> #x810B9FE>)

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
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>