trapni

it has never been the way you described it, unless someone can proof it. I would wonder if windows would do it differently. Although, I'd highly appreciate a _dynamic_ load/unload (ignoring the reload with state-keeping for now). This shall be possible by designing _clean_ load() and unload() hooks the dynamically script library is hooked into (and implements properly himself). The unload shall get some special care, because any reference from withing a library to be unloaded may result into funny results after having unloaded the libarary (on access) - this shall also apply for windows, I assume. ( But again, valgrind can help there From a UNIX library's API point-of-view, a library is completely open, unless compiled with -fvisibility=hidden which would require to declare anything in the public API to be __attribute__((visible)) - think of a nice macro here, that makes it fine for windows (declspec) and GCC/UNIX. Regards.

i feel a little misunderstood, yes, i heard of sd2, and that's why i even thought about suggesting this - to make mangos a little more configurable. sd2 is currently compiled as part of mangos, thus, the Makefiles have to be patched, using "git-am src/bindings/ScriptDev2/patchfile". this is sooo hardcoded and ugly, and that's why I wanted to propose to provide some kind of configuration line, e.g. LoadScript = /usr/libexec/mangos/ScriptDev2.so which shall then be part of mangosd.conf. Then SD2 shall be compilable from the outside world, and not from within mangos itself. This at least would make packaging mangos and sd2 as a pluggable part much more easier.

ok, i found it, but still, you've to patch mangos build tree, and give it a fixed name instead of a configurable one.

Hey guys, what i was always wondering about, is: mangos comes with a default (pretty no-op) script library. this library seems never to be used and just serves as an example for this interested in runnign mangos. This actually leads to to case where though nearly everybody needs to "patch" the mangos to replace the statically linked script libary with their own, or the one they want, however. Why is this done the ugly way? What are the cons against loading this library dynamically and letting the configuration decide what plugin to load (and from where). This way, it would come in handy for more ppl, not just sysads I'd try to write the little chunks to load this piece dynamically, but I fear that my calls would just work on UNIX systems as i've no clue of win32 implementations (though, could provide empty #if's)

unfortunately not. honestly, however:when a thread (or process) raises SIGSEGV, the application is going to crash, whatever you're about to try to go against it. it *will* abort with this signal. SIGSEGV is the signal that is raised on typical programming errors. These errors can be faught against. e.g. by implementing assertions (UO Sphere does that, obviousely) which are a set of conditionas being performed right before the actual function code is performed. or right after the function has returned, in the parent function. These assertions can then soft-abort the current thread, e.g. by C++ exceptions. which can then be caught somewhere upper in the callstack where it is save to catch it and just forget about the inner things (e.g. by good designed class destructors). Obviousely, UO sphere does that. Next: There actually is a way in catching a SIGSEGV without quitting the whole virtual world - UNIX mail agents and www servers have shown that it works perfectly. But this comes at a price. The service (in our case: mangos) has to be written extensively multi-process'ly, that is, instead of spawning child thread, it will fork into child processes, and setup communication pipelines. So a client child process may indeed SEGV, which might just result into a player client just disconnecting OR an object (e.g. Malygos) just disappearing, because the client process serving this world object just died away. That's not bad at all, but in the latter case you still have write stable communication lines and the core shall be stable aswell, of course, too - but client processes might fail as often as they'd like. The latter has an advantage, though, you could go and run this service on a cluster where each process may be balanced from once CPU/host node to another, which isn't as easily done in a multi-threaded service. my personal objection: just use valgrind[1] to find the bugs and stay with the multi-threaded way. at the end: i love users myself running my applications within valgrind (or simply gdb the core files) in order to provide a much better bug feedback then just saying "it crashes somehow". Cheers. [1] http://www.valgrind.org/