Hi Tommi
We have been using tntnet for a few years now and we are very happy with
it however I want to once again draw your attention to the problem with
RTLD_GLOBAL being set. It came up today because we had a server with the
default install of cxxtools and we could not run two instances of the
same application due to threading problems. Once we changed the
RTLD_GLOBAL setting to RTLD_LOCAL (as we always do now) tntnet became
stable again.
RTLD_GLOBAL is a dangerous option and will reliably fail each time you
try to run two instances of the same application (as we often do).
Namespaces (as per our reply below) do not solve the problem.
In our humble opinion, using RTLD_GLOBAL is not a good programming
strategy however you may need to use it to accommodate your customer
base. Our suggestion is to make it a compile option, with the default
being set to RTLD_LOCAL.
From Sep 2008:
Today's Topics:
1. Re: RTLD_GLOBAL issues (Paul)
----------------------------------------------------------------------
Message: 1
Date: Tue, 02 Sep 2008 13:08:02 -0700
From: Paul <[email protected]>
Subject: Re: [Tntnet-general] RTLD_GLOBAL issues
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Tommi,
If you consider the problem carefully you will find that namespaces do
not resolve this serious issue. It can at best only reduce the
probability of the problem appearing but will not eliminate them, since
you cannot expect to everyone to always use different namespaces in
their libs that are NORMALLY kept local to the shared lib.
And then there's the other serious problem we've had with the threading
(namespaces will definitely not solve that one no matter how carefully
the namespace is chosen). We've had serious problems writing to files
from threads with RTLD_GLOBAL set. With RTLD_LOCAL it works perfectly.
Of course the true problem is with the fact RTLD_GLOBAL allows a very
dangerous programming environment to exist. I'm not certain if this is a
problem with C++ or the ELF system however either way you should switch
to RTLD_LOCAL or at the very least make it a default config setting.
Many people experiencing the unwanted shared routines will crash in very
ugly and unpredictable ways and they may blame tntnet without
understanding the root cause. Also, discovering the problem will likely
only happen after a tntnet application becomes relatively advanced which
is often a difficult time to debug a memory related problem such as
this. We had to created simplified test applications to route out the
problem, I don't know if others will have the same patience.
Again, tntnet is very stable with RTLD_GLOBAL having been replaced with
RTLD_LOCAL. Without it, we could not use tntnet in multiple application
scenarios which would be unfortunate because tntnet is a wonderful model
and deserves wide spread usage.
Paul
On 01/09/08 12:01 PM, [email protected] wrote:
> > Send Tntnet-general mailing list submissions to
> > [email protected]
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.sourceforge.net/lists/listinfo/tntnet-general
> > or, via email, send a message with subject or body 'help' to
> > [email protected]
> >
> > You can reach the person managing the list at
> > [email protected]
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Tntnet-general digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: RTLD_GLOBAL issues (Tommi M?kitalo)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Sun, 31 Aug 2008 21:36:31 +0200
> > From: Tommi M?kitalo <[email protected]>
> > Subject: Re: [Tntnet-general] RTLD_GLOBAL issues
> > To: [email protected]
> > Message-ID: <[email protected]>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Hi Paul,
> >
> > thank you for your analysis. I see the problem. Usually I put my
code into
> > namespaces to prevent these problems but I should not expect the
users of
> > tntnet to do so.
> >
> > The main reason, why I once changed thie RTLD-flag is, that I had
problems
> > catching exceptions. But there might be already a solution for this.
> >
> > If exception classes are all inline (header only), each link unit
instantiates
> > its own type and one link unit do not recognize the exception of
another link
> > unit. The solution is not to inline all of the exception class.
> >
> > I'm not sure, if there are other problems. I need to do some
testing with
> > RTLD_LOCAL. But I prefer not to create a configuration option.
Maybe there
> > are indeed better solutions for the problems I had with RTLD_LOCAL.
> >
> > Tommi
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Tntnet-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tntnet-general
