Gerrit Voss wrote:
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.
True. It was just a suggestion.
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.
Ok. Maybe osgInit doesn't fit. Come to think of it, I call osginit
statically, not in DllMain(). At that time, all OSG-dlls are loaded &
initialized, since my dll depends on them.
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.
You can always change the aspect afterwards, right? The main problem is
that OpenSG chokes horribly on threads that has no aspect assigned to
it. This happens a lot with external threads that are created and then
quit the application (java, ctrl-break routines, etc). I don't know if
this is occurs more on Windows than other OS:es though.
If the execution find it's way into my code, I suppose I would be able
to check/change the aspect of that thread into something correct.
Short comment on the code itself ;-), sorry could not resist.
> [snip]
Yeah. Ok. :)
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 ;-))
Heh. Understandable. But is the thread-aspect initialization (my main
point in the mail) easier to get in there, portably?
Regards
/Marcus
-------------------------------------------------------
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
