Lisp HUG Maillist Archive

CAPI and multiprocessing

Hi folks,

The documentation states that

Operations on CAPI objects are not atomic in general. The same is true for anything in the IDE. These operations need to be invoked from the thread that owns the object, for example by capi:execute-with-interface or capi:apply-in-pane-process ..

Is this true also for added slots in a derived class?

I have an interface class (defined with define-interface) with some custom slots. I'm experiencing strange problems where one of those slots is suddenly set to nil. My only guess is that it has to do with multiprocessing somehow, but before wrapping every call to these slots in capi:execute-with-interface, it would be nice to know if that can possibly have any effect.


A second question is if the number printed by print-object is supposed to be a stable memory location. I get the following in my log:

click-callback  (capi:top-level-interface self) = #<USER:TEST-PANEL "Test" 200F0FBB>
click-callback  (capi:top-level-interface self) = #<USER:TEST-PANEL "Test" 200F0FBB>
…
click-callback  (capi:top-level-interface self) = #<USER:TEST-PANEL "Test" 24225C7B>

Is this "normal", or does it indicate that the interface has been "replaced" somehow?


Regards
Erik


Re: CAPI and multiprocessing

>>>>> On Sat, 3 Mar 2012 15:19:25 +0100, Erik Ronström said:
> 
> Hi folks,
> 
> The documentation states that
> 
> Operations on CAPI objects are not atomic in general. The same is true for
> anything in the IDE. These operations need to be invoked from the thread
> that owns the object, for example by capi:execute-with-interface or
> capi:apply-in-pane-process .
> 
> Is this true also for added slots in a derived class?

Slots added by define-interface are normal standard-object slots, so access to
each slot is atomic with respect to modification of that slot and with respect
to class redefinition.

Note however that access to multiple slots or multiple accesses to a single
slot isn't an atomic operation overall.  For example, the form

(with-slots (foo) object
  (+ foo foo foo))

access the slot foo three times, because with-slots is defined using
symbol-macrolet.



> I have an interface class (defined with define-interface) with some custom
> slots. I'm experiencing strange problems where one of those slots is
> suddenly set to nil. My only guess is that it has to do with multiprocessing
> somehow, but before wrapping every call to these slots in
> capi:execute-with-interface, it would be nice to know if that can possibly
> have any effect.

Using capi:execute-with-interface is probably best anyway, because it avoids
problems with the order of multiple slot accesses.


> A second question is if the number printed by print-object is supposed to be
> a stable memory location. I get the following in my log:
> 
> click-callback  (capi:top-level-interface self) = #<USER:TEST-PANEL "Test" 200F0FBB>
> click-callback  (capi:top-level-interface self) = #<USER:TEST-PANEL "Test" 200F0FBB>
> …
> click-callback  (capi:top-level-interface self) = #<USER:TEST-PANEL "Test" 24225C7B>
> 
> Is this "normal", or does it indicate that the interface has been "replaced" somehow?

This is normal -- the number is the address of the object in memory and
garbage collection might move it.

-- 
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/


Updated at: 2020-12-10 08:36 UTC