[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MzScheme Special Form -> Native Numerical Code?



"Paul A. Steckler" wrote:
> 
> >Also, once MzScheme can run dynamically loaded machine code, I could
> >more easily extend the system under Windows. There is an issue with
> >using Windows DLLs in that all users of a DLL share the same global
> >variable space, and so a user runs two MrEd-type sessions using the same
> >DLL, there is a potential for conflict (if a global variable is say set
> >with a pointer to a VM). For what I've seen of doing MzScheme
> >extensions, it appears this may be a problem in the MzScheme case
> >(because a VM isn't passed in as a function parameter.) I don't believe
> >this is an issue under Unix or the Mac, which I think both load
> >extensions into the executeables address space.
> 
> Are you sure that all users of a DLL share global variables?
> I believe that is true *within* a process, but untrue *between*
> processes.
> 
> -- Paul

Well, I always might be wrong... 
It looks like you are totally correct.
Thanks for pointing this out.

I've reviewed some of the related documentation. Here is a clear
statement supporting your point:
http://www.inprise.com/techpubs/delphi/delphi5/oplg/dllpackg.html
And also:
http://x71.deja.com/getdoc.xp?AN=591987366&CONTEXT=965423663.1557921816&hitnum=1

It appears my information is out of date. What I said was true for
Win16, and I probably read in it a Windows 3.1 development book many
years ago now that I think back. It is not true as the default for
Win32. See, for example:
http://x71.deja.com/getdoc.xp?AN=603379772&search=thread&CONTEXT=965423799.1558052884&HIT_CONTEXT=965423663.1557921816&HIT_NUM=6&hitnum=13

General reference:
http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/winbase/dll_512r.htm
Specifically:
  http://msdn.microsoft.com/library/psdk/winbase/dll_512r.htm
  http://msdn.microsoft.com/library/psdk/winbase/dll_1tpv.htm
Also:
  http://www.geocities.com/Tokyo/Towers/6162/win32/dll/make.html
Especially:
  http://msdn.microsoft.com/library/psdk/winbase/dll_9khl.htm

In this last it says: "Note that the shared memory can be mapped to a
different address in each process. For this reason, each process has its
own instance of the lpvMem parameter, which is declared as a global
variable so that it is available to all DLL functions. The example
assumes that the DLL global data is not shared, so each process that
loads the DLL has its own instance of lpvMem."  

This also seems to substantiate what you are saying, if "the DLL global
data is not shared". I don't know how to specify this, assuming it is
not the default. Actually, it appears from this that it is the default
and you have to go out of your way to cause the globals to be shared:
http://x71.deja.com/getdoc.xp?AN=603175542&search=thread&CONTEXT=965423799.1558052884&HIT_CONTEXT=965423663.1557921816&HIT_NUM=6&hitnum=12

It had been my (apparent incorrect in the Win32 default case!)
understanding that all users of a Windows DLLs share the globals defined
in the DLL. However, each caller of the DLL is using its own stack
space. What I had thought this meant in practice is that you are safe in
writing a DLL likely to be used by two applications at once if you
always pass in any data you need for each function call. As soon as you
start storing data in globals, I had thought you risked problems if that
data is stepped on (or even used) by another application. It turns out
this is only the default case in Win16, not Win32, which is what
MzScheme is running under. However it is still the case that since each
application may have its own address space, pointers put in explicitely
shared globals by one application may not be meaningful from another
application's point of view (unless the pointer has been created as a
shared memory pointer). However, that problem won't arise unless you
explicitely share the variable.

Thanks for setting me straight. What knowledgeable people are on this
list!
If I hang out here, maybe I'll become one of them. :-) Sorry for
spreading misinformation regarding Win32.

By the way, an interesting Microsoft article on DLLs (and especially
Windows 2000 changes) is here:
  http://msdn.microsoft.com/library/techart/dlldanger1.htm

-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