I’ve been running into a issue with a custom plugin. When unity loads the dll for the first function call from it, it doesn’t free the module itself. So if i press play, some dll function is called which loads my dll and then press stop my module does not get free’ed. I’ve made a work around for this by making a wrapper dll which calls LoadLibrary and FreeLibrary and then GetProcAddress for each function inside the wrapped dll so i have more control over it.
Anyways i was just curious if that is default behavior. Could it be that some how i’m holding the module open? or does mono just not restart completely and holds the module in place. I can see the reason for just keeping it open but its really kind of a pain since each time you press play its like launching the program and stop is like closing it.
BTW i’m using a windows dll with unity pro 3.4.1 and i’m talking about DllImport, not a .net compatible dll.
This is the default yeah.
The problem is that the play mode and the editor are the same mono environment and as unity does not unbind the dll, only ‘drop it’ when the app is terminated ie the mono environment, the dll is not unhooked until the whole editor went down. Its not really favorable and leads to all kind of very annoying and time wasting side effects but beside loading it manually yourself there is no option
and you don’t need a wrapper dll. Wrap the win32 calls directly in a C# file in Assets/Plugins using the interopservices and do it from there
Thanks dreamora. That explains why i’ve had to take this approach.
Loading manually is all i’m doing in the wrapper dll( LoadLibrary and FreeLibrary ) i basically need to do this to clean up any thread work and have the plugin actually act as if it were loaded. I only use the wrapper when in the editor however. So my wrapper sticks on with unity but the dll it loads and unloads doesn’t.
I’ll just have to keep going about it then. I really wish there was a library for windows plugins one could use for things like the threadsafe UnitySendMessage on ios.
Well you could easily create a UnitySendMessage counterpart by exposing such a delegate that hooks to a static function on the unity side pulling it off
but otherwise it would be impossible as dynamic binding means the dll beside provided callbacks wouldn’t know about the existance of the outer world at all, but a ‘init plugin’ function that feeds the delegate is all thats needed so really relatively easy
the only thing I wouldn’t do is make it like send message. You are calling into a proper non ‘good luck’ layer so make use of it, use Event Handlers etc to send the messages, not ‘string good guessing’ and realtime reflection on one or more objects
yea don’t get me wrong, i don’t like UnitySendMessage. Just it would be nice to not have to have almost completely seperate code per platform. I really don’t know how accurate the docs are on things like UnitySendMessage’s async memory or how they say Dll calls are so slow you shouldn’t have more than one per frame. If it wasn’t expensive to make dll calls on ios i would just have a syncronize native function and call it every and use it to communicate whats going on in the native side back to unity immediately and that would work on all platforms.
I’ve thought about using marshalling to just have unity read some static buffer’s memory with state information via some returned IntPtr, but have not done it because i would think that would be just as slow as a dll call, and probably put alot of stress on the gc heap.
Where are your refences that dll calls are slow? We have input devices that capture human movement which use callbacks and basic function routines to send data to unity and have unity sending feedback back to other devices. Never had any slow downs
Agreed, DLL Calls are definitely not slow. They are slower than having it purely in C# naturally due to crossing the border of managed to unmanaged with the data and all the related overhead, but even networking is possible to be done this way (did a netdog implementation in 2009 which is pretty high on the call count as any networking)
I definitely have not noticed them being slow either, but the user manual says they are:
[iOS Tips
Managed → unmanaged calls are quite expensive on iOS. Try to avoid calling multiple native methods per frame.](Unity - Manual: Plug-ins)
overlooking the doc again, they used to say UnitySendMessage did not copy the string so you’d have to keep it in memory untill a frame has passed. They no longer say that and thats a little frustrating considering the amount of work that went into supporting that. I had a feeling that was never a requirement.
