RE: Lua 5.0 beta/loadmodule question

["Brett Kapilik" <brett@...>]

I agree.  This could be a serious problem when creating extension DLLs.  I finally solved the problem by re-writing the luaM_realloc function to use HeapAlloc, HeapRealloc, and HeapFree.  I also had to write my own implementation of loadmodule to work with this new sceme as well.  However, now everything works across the DLL properly.  Unfortuantely, now any extension modules that are made for our product will have to link in with my "special" version of Lua, but that is an acceptable trade-off for us for the time being.

In my opinion, Lua could definitely benefit from some way to use shared memory between an application and a DLL in Windows.  Anyone who implements Lua in a Windows application that statically links to the C runtime library will run into this same problem, I believe.  Hope my pain and suffering for the past 4 days can help someone else out there :)

- Brett

> -----Original Message-----
> From: Bilyk, Alex [mailto:ABilyk@maxis.com]
> Sent: Monday, March 10, 2003 4:30 PM
> To: Multiple recipients of list
> Subject: RE: Lua 5.0 beta/loadmodule question
> 
> 
> It is a problem indeed. Heap allocation/deallocation doesn't 
> work across DLL boundaries. Besides the general note, same 
> thing happens in C++ when trying to pass STL containers 
> across DLL boundaries. The way we handle this for STL is 
> using a single instance of a global allocator for such 
> containers to make sure the memory for them comes from the 
> same memory pool. GlobalAlloc would help, but what would help 
> even more is if Lua was made in such a way as to accept 
> memory interface dynamically from the client application. 
> This had been discussed but current implementation offers 
> only statically bound allocation interface, unlike the 
> dynamically bound data sources added to Lua 5. 
> 
> AB
> 
> > -----Original Message-----
> > From: Brett Kapilik [mailto:brett@indigorose.com]
> > Sent: Monday, March 10, 2003 1:56 PM
> > To: Multiple recipients of list
> > Subject: RE: Lua 5.0 beta/loadmodule question
> > 
> > 
> > I have not tried the DLL thing yet.  However, I hace been 
> > looking more at the problem and I think that I have a handle 
> > on it a bit more.  My application statically links the MFC 
> > libraries.  This means that it links with the static version 
> > of the C runtime library.  This means that my app keeps a 
> > different heap for itself that is seperate from the one that 
> > the extension DLL uses.
> > 
> > That is the problem.  So for example, if I have a function in 
> > my extension DLL like so:
> > 
> > static int testlib_sayhi (lua_State *L)
> > {
> > 	MessageBox(NULL,"Hi","1",MB_OK);
> > 
> > 	char szHi[10];
> > 
> > 	lstrcpy(szHi,"Hello");
> > 
> > 	lua_pushstring(L, szHi);
> > 
> > 	return 1;
> > }
> > 
> > it also causes the same problem.  In the function above, 
> > lua_pushstring ultimately calls the C runtime function 
> > realloc which creates the string on the DLL's heap.  Then 
> > when my application exits and calls lua_close, lua_close 
> > causes the assertion because it is trying to free memory from 
> > my application that was allocated from the extension DLL.  
> > Does that make sense?
> > 
> > I think my solution is to go into "lmem.c" and re-write the 
> > luaM_realloc function to use GlobalAlloc and GlobalFree in 
> > order to share the heap between the DLL and the application.  
> > Has anyone ever done that before?  Any other ideas?
> > 
> > Regards,
> > 
> > Brett
> > 
> > > -----Original Message-----
> > > From: Wim Couwenberg [mailto:w.couwenberg@chello.nl]
> > > Sent: Monday, March 10, 2003 3:24 PM
> > > To: Multiple recipients of list
> > > Subject: Re: Lua 5.0 beta/loadmodule question
> > > 
> > > 
> > > Hi,
> > > 
> > > > MyApplication - Includes the lua .h files and lua.lib 
> and luaD.lib
> > > > ExtensionDLL - Includes the lua .h files and lua.lib and 
> > > luaD.lib - this is the extension library loaded using loadmodule.c
> > > 
> > > Do I understand correctly that both your app and extesion
> > > link against the static lua libs?  Then two incarnations of
> > > the lua environment exist in the same process and that
> > > doesn't sound promising...  Did you try linking both your
> > > app and the extension against a dynamic lua lib, so lua gets
> > > pulled in (from the lua.dll) only once?
> > > 
> > > It is safest to build a lua.dll from your own project,
> > > because mixing prebuild binaries can be a problem in itself
> > > (as reported earlier on this list.)  Make sure that a
> > > dynamic version of the runtime lib is used everywhere...
> > > 
> > > Bye,
> > > Wim
> > > 
> > > 
> > 
> > 
>