Hi Tommi, I'm replying in place of Paul as he's been too busy with coding lately to reply in a timely manner.
>>I'm really willing to help. Lets talk about possible solutions. First of all I >> have this: http://gcc.gnu.org/faq.html#dso. So if we change loading to >> RTLD_LOCAL, we loose the chance to catch exceptions thrown from >> webapplications. Or at least we loose the chance to get informations about the >> exceptions. I read over the item you have linked, but I don't fully understand it. In our situation we have over 100 shared libraries making extensive use out of exception handling and so far there's been no limitations noticed with throw/catch, type_id, or dynamic_cast despite always using RTLD_LOCAL. We've been using g++ 4.x series which perhaps has resolved the issue since the 3.x series - is there still a need for RTLD_GLOBAL? >>Tntnet can still do a "catch (...)" and send a unknown error. We just loose >>the message from std::exception::what(). That's what tntnet is doing already. In our case we're catching all final uncaught exceptions inside the ecpp component used by our web application. In our view it makes little sense to pass these exceptions on to tntnet for final processing. The general rule for us is that it should be the web applications responsibility to catch and deal with all exceptions that may be generated by itself. It is extremely trivial to do so, and a final catch(...) can be included to make sure that unknown exception types that are not derived by std::exception are caught. If for whatever reason RTLD_GLOBAL remains as a requirement, I offer my thoughts on your list of proposed solutions ... >>1. We can change the loading mechanism by configure-flag. I don't like that, >>since we get different binary versions of cxxtools. I agree, having two binaries is not a good idea. >>2. We can set a environvariable, which indicate, which loading mechanism to >>use. Environment variables lie outside the control of the running application and therefore may change expectantly during runtime, as a result this is an unreliable solution. >>3. We can introduce a additonal parameter. This is platform specific and we try >>to get our API platform indipendent. With C++ overloading you can have two functions with the same name, one without and the other with the dlopen mode parameter. This will give the appearance that the API has not been changed for those who have no need for specifying a dlopen mode. Another option is to extend the cxx_dlopen() function with a defaulted parameter to either RTLD_LOCAL or RTLD_GLOBAL (or whatever default flags you choose), and if the load option is not available on a specific platform, the argument can simply be ignored. The addition of an optional dlopen mode parameter is very flexible because any set of dlopen flags may be specified by the user of the API, rather than being stuck with a limited set of options. In any event, with respect to tntnet, it is tntnet that is making use of the loading mechanism used by cxxtools, therefore a dlopen mode choice will have to be made one way or the other which gets us no where if it does not meet the needs of the tntnet user (as it is in our case). One solution is to add an option to tntnet.conf to specify the dlopen() behaviour. In fact there may be other modes the user will want to specify, which currently require an inconvenient source code modification and recompile of cxxtools to realize. In my opinion, using a tntnet.conf option to specify the dlopen mode is a very flexible solution that should be explored. >>4. We can add some prefix to the library name, which idicates the mode. So you >>can specify in tntnet.conf, which loading mechanism to use for each library >>separately. >>I like the last suggestion. If you want to load a library "myLib" with >>RTLD_LOCAL, you just specify e.g. "!myLib" as the library name. The loader in >>cxxtools sees the exclamation mark, removes it and uses RTLD_LOCAL. We do not >>need to change the API then. >> >>What do you think? The "!" solution may work well for those who are developing applications with cxxtools, but in our case it is tntnet that is loading our web application using the cxx_dlopen() function, which in turn uses RTLD_GLOBAL, therefore we will need a method of telling tntnet to load the web application with RTLD_LOCAL instead of with RTLD_GLOBAL. It seems to me that the best place to do so will be in the tntnet.conf file using whatever method you think is best. Thanks for looking into this! Robert ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Tntnet-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tntnet-general
