Posted by HMC in Plugin Development on Jun 27 2008, 06:34 am

Hi everyone,

As everyone who has been following my 'journey' is probably sick of hearing:

I have one instance of an object in a dll loaded by callDLL.
Each method of the class is called through a seperate method of callDLL and obviously the properties of the class are shared across the method calls;

the plugin is not returning the results I expect; is this likely to be an issue caused by multithreading ?


Posted by Dan in Plugin Development on Jun 27 2008, 08:12 am

Gareth,

Could you give us a bit more background into your scenario? Is the dll that you're calling (through calldll), one that you built. or a canned "don't have access to source code" library?

The reason I ask is that going through calldll adds another layer of indirection which may not be necessary, and which could be adding unnecessary complexity.

Calls to the plugins, and hence your dll, are done on seperate threads. There are numerous advantages to this approach (we won't discuss those now), but the disadvantage is that threading issues sometimes come up. For example, some (poorly designed?) objects you might want to use in a plugin or downstream dll might have some form of thread local storage that might not be automatically initiallized, or may try to access resources (memory or hardware) in an uncontrolled fashion. I've never seen a scenario, though, were the problem wasn't solvable. It's just a matter of effort, and clearly understanding the problem.

By the way, if you're uncomfortable discussing details that could be proprietary in such a public forum, we can always discuss this more via email (support@northcode.com). I encourage you to keep the discussion here as much as possible, though, since there are several users out there that have experience with plugin development on various platforms, and theiir insight may be beneficial as well.


Posted by HMC in Plugin Development on Jun 27 2008, 09:45 am

Hi Dan,

Yes of course,

I have re-factored some c code for fluidDynamics into a c++ class, which I now implement in a DLL called fluidPlug. I load fluidPlug through the callDLL, which I intend to use as a harness for any further plugins I (hopefully) develop. The fluid dynamics class is instantiated on DLL_PROCESS_ATTACH and then methods of the single instance are called through fluidPlugs interface. The various methods of FluidPlug have various properties of the class in common, for example an array of velocity values. Calls to fluidPlug are made through the interface of callDLL; I could simplify the dependency chain by removing callDLL.

The class is very simple and does not implement any threading.

Whilst the project that I am working on is under NDA the details of this particular code is not a matter of secrecy :)



update, I am reporting from deep inside the debugger and it seems the problem is in the arrays that I am using, the first element seems to be the correct value but further elements are incorrect ?


Posted by Dan in Plugin Development on Jun 27 2008, 11:03 am

If it was me, I'd simplify things. Unless you have a good reason to keep that extra layer with calldll, I'd suggest you just make a plugin out of your dll. Making use of PROCESS_ATTACH to create objects is very often a bad thing. For example, when you use Windows Explorer to look at the properties of a dll, Explorer loads it, and dllmain gets called with PROCESS_ATTACH. Often, this can result in side effects, especially if your constructor does a lot of work, or accesses hardware.

With the design of the Plugin SDK, there really isn't that much baggage to be added to your base code, and you won't have to worry about issues with mismatched calling conventions. In addition, you'll gain the benefit of being able to instantiate multiple instances of your plugin object within your ActionScript code.

A note on multithreading. Bear in mind that the fact that your code doesn't directly make use of multithreading doesn't mean that you're immune to the effects/issues related to it. The plugin library is multithreaded, and since it calls your code, you have to consider the effect. That being said, it's usually not a problem.


Posted by HMC in Plugin Development on Jun 27 2008, 11:22 am

If it was me, I'd simplify things. Unless you have a good reason to keep that extra layer with calldll, I'd suggest you just make a plugin out of your dll. Making use of PROCESS_ATTACH to create objects is very often a bad thing. For example, when you use Windows Explorer to look at the properties of a dll, Explorer loads it, and dllmain gets called with PROCESS_ATTACH. Often, this can result in side effects, especially if your constructor does a lot of work, or accesses hardware.

I'll read up on this, I was just following a tutorial :D Could you elaborate on why it is a bad idea ?

A note on multithreading. Bear in mind that the fact that your code doesn't directly make use of multithreading doesn't mean that you're immune to the effects/issues related to it. The plugin library is multithreaded, and since it calls your code, you have to consider the effect. That being said, it's usually not a problem.

Understood :)


Posted by Dan in Plugin Development on Jun 27 2008, 01:48 pm

Dlls get loaded into memory for a number of reasons, and sometimes they're loaded just to access resources (e.g. icons, etc.). In those cases, the code is never meant to run, so getting all fired up and initializing the world is a waste of effort, time, CPU and memory. Keep in mind that this quick loading (and it's supposed to be quick) could happen frequently / repeatedly.

Raymond Chen, not surprisingly, has an article on this matter which explains things better than I ever could: Some reasons not to do anything scary in your DllMain


Posted by HMC in Plugin Development on Jul 01 2008, 11:43 am

Hi all,

I have finally suceeded in building and integrating my first Plugin Woot!

and my actionscript project runs... slooooooooow, (2000+ calls to an array in the DLL for the render loop == bottleneck) Onoes!

So I guess it's back to the drawing board as regards this project maybe do the whole thing in openGL, but I just wanted to extend my enormous gratitude to those who have helped me along the way :D

Thanks!


Posted by northcode in Plugin Development on Jul 02 2008, 02:05 am

How much data are you passing back and forth between the plugin and Flash? Marshalling data is going to be expensive. I have no idea what you're doing :) but 2000+ calls is probably producing more data than you can render in Flash in real time. Is there any way you can reduce the number of calls and pass the data in batches?


Posted by HMC in Plugin Development on Jul 02 2008, 04:28 am

Hi Tim,

I am passing a 2d array / matrix between the plugin and Flash, I don't think it is too much to render personally, I timed transfer and render times and due to the repeated calls to 'get array entry x, y' it takes about 15 seconds to clear the matrix and about 0.4 seconds to render.

I don't think there is much that can be done about this since AFAIK I can't pass an array and if I 'streamed' the values (like some kind of progressive render) to counteract the bottleneck, the screen updates would be laggy in response to user input :(


Posted by northcode in Plugin Development on Jul 02 2008, 10:23 am

How much data are we talking about (each way) and how often do you need to call the plugin to get updated results?


Posted by HMC in Plugin Development on Jul 02 2008, 11:16 am

4096 array elements called by actionscript from the ss plugin on each update loop - hopefully on an interval of 40 milliseconds / 25 fps. XD a negligable amount of data is sent in the other direction.