Hi,

On Wed, 2006-03-22 at 17:04 +0100, Marcus Lindblom wrote:
> Hi all,
> 
> I've been messing about with dll-initialization a bit (since we moved 
> our project to dll's recently). I've managed to write up something that 
> ensures that every thread created in the process which has my dll loaded 
> always has it's OpenSG-aspect data initialized. It wasn't very hard.
> 
> For OpenSG, it would be something like the code I've included at the end 
> of this mail. This would be included in the lib (probably OSGBase) that 
> defines all the thread stuff.
> 
> If you wanted, you could even put osgInit(0,0) in the 
> DLL_PROCESS_ATTACH, since the cmd-line data doesn't seem to be used at 
> the moment. (That's what I do in my dll, so that all the little exe's I 
> got doesn't have to bother with initializing anything, they just link to 
> my dll and start using stuff).

hmm, this seems a little bit special as it disallows doing anything
before osgInit is run. There are at least two things I would like to
be able to do, register additional dlls to be loaded and modify the
multi threading parameters (number of aspects, as recompiling to
change to number of aspects is kind of suboptimal ;-)).
At least the second one must be done before osgInit is called. 

A second point I have to check is exactly  when does DllMain get
executed especially in relation to the initialisation of all OpenSG dlls
loaded. In particular the static elements of, for example OSGSystem,
must be initialized before DllMain of in this case OSGBase is run
otherwise the type system won't come up correctly.

The thread attach part for external threads is interesting but also
a special case because the aspect id is fixed. Also the interplay
with OpenSG threads would be interesting to observe. Two quick
solutions for the aspect would come to mind, use a variable and provide
a function to set it or use a macro the tailor DllMain to the current
needs.

Short comment on the code itself ;-), sorry could not resist.

>             osg::BaseThread * thr = osg::ExternalThread::get(0);
>              if (!thr->isInitialized()) {
>                  osg::ExternalThread::get(0)->initialize(0);
>              }

the if should always be true because IIRC get with no thread name returns
a new one every time it is called. So you can just do 

thr->initialize(0);

and save one of the two threads you create. Or just do

osg::ExternalThread::get(0)->initialize(0);


But the major concern I would have is how to get it running across
all the different platforms like MacOS or Linux. I tried something like
this before with Linux and it was a major pain because with every other
compiler and bin tools version the way to do it was different and
sometimes it magically interfered with other parts of the so init like
static elements. While it is interesting to mess with the general so
initialization there a things that are more fun to do ;-))

regards,
 gerrit












-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to