All-

I need to retract these comments regarding possible shared global variable difficulties with Squeak pluggable primitives as DLLs under Win32.

It turns out that what I said regarding problems with shared globals between applications (processes) is only the default for Win16 (so my knowledge on this was out of date).

Under Win32, by default, every application (process) has its own copy of global variables in a DLL. So there is no problem I can see now to this approach for Win32 pluggable primitives.

See for example: http://x71.deja.com/getdoc.xp?AN=603379772&search=thread&CONTEXT=965...

Someone on the MzScheme mailing list http://www.cs.rice.edu/CS/PLT/packages/mzscheme/index.html was kind enough to point out my misunderstanding regarding Win32 DLLs and the default case for globals, and I didn't want to let my passing on this misinformation cause any more confusion here.

-Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com

Paul Fernhout wrote:

Stefan Matthias Aust wrote:

...

static struct VirtualMachine *VM;

EXPORT int setInterpreter(struct VirtualMachine *interpreterProxy) { VM = interpreterProxy; return 1; }

EXPORT void test(void) { int test = VM->stackIntegerValue(0); VM->popthenPush(1, VM->integerObjectOf(-test)); }

I haven't looked into the latest pluggable primitive stuff, but the approach implied in this code concerns me for use in a Windows DLL. When exactly does "setInterpreter" get called? By whom? How often if you are running multiple Squeak EXEs?

A Windows DLL shares its globals with all users of it. Assume "setInterpreter" is called once by each EXE using the DLL. This would mean that if you started up two Squeak sessions, the second one would also set its interpreter, setting the shared global variable. This means calls by the first VM to "test" afterward would now internally use the reference to the second VM, which because of address space issues may point to garbage instead of either VM.

It is my understanding that the "right" way to do this under Windows to allow multiple sessions to use the same DLL is to pass a pointer to the VM into every call.

Remember: the stack used by DLL functions is provided by the caller; the global variable space is shared by all users of the DLL (and is unique to the DLL). Also, remember that since different Windows processes may have different address spaces, a valid pointer in one address space may point to garbage in another address space unless the pointer is explicitly created as shared memory. I believe the address space is always resolved relative to the caller.

Note that the code above is completely valid and appropriate if it is statically linked into the VM. In that case, it would share the VM's global space, and a new global storage location for the modules VM pointer would of course then be allocated for every new application process running the VM

Note also that the above code might also be valid in a DLL if the VM was a shared resource used by all callers of the DLL. This would be valid in the case where all Squeak EXEs shared one running shared VM, and multi-threading issues were resolved using locks and semaphores (perhaps with the DLL function getting a lock on the VM before proceeding), VM calls were rentrant, and any namespace issues were resolved. I believe this is now the case with Python (whose VM is in a DLL under Windows) -- but as I understand it was tough sledding to do it and it requires care in its use. This takes us back to some post years ago on this list related to the difficulty of adding reentrancy in Squeak...

-Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com