Hi Drazen,
Yes, it will be in 1.5.
Dave
"Drazen DOTLIC"
<[EMAIL PROTECTED] To:
<[email protected]>
rema.com> cc: (bcc: David N
Bertoni/Cambridge/IBM)
Subject: RE: Xalan initalization
03/14/2003 09:01
AM
Hi Dave,
That's exactly what I was thinking - small accessor just to check if the
initialization was done or not, with a clear (big red flashing letters
:) ) indication that it is not thread safe in the docs.
In the meantime, I think we will just leave the leak and fix it
permanently with the next upgrade - this feature should end up in Xalan
1.5?
Thanks again,
Drazen
> -----Original Message-----
> From: David N Bertoni/Cambridge/IBM
> [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 14, 2003 5:47 PM
> To: [email protected]
> Subject: RE: Xalan initalization
>
>
>
>
>
>
> Hi Drazen,
>
> Actually, I'm not implying the leak is that small, although it's not
> necessarily that big. The problem is the initialization can step on
> objects that other threads may be using. This could cause lots of
> problems.
>
> I'm going to add an accessor the see if the library has been
> initialized,
> with the caveat that this check is not thread-safe. You will need to
> serialize the calls to this accessor.
>
> Dave
>
>
>
>
>
>
> "Drazen DOTLIC"
>
>
> <[EMAIL PROTECTED] To:
> <[email protected]>
>
> rema.com> cc: (bcc:
> David N Bertoni/Cambridge/IBM)
>
> Subject: RE:
> Xalan initalization
>
> 03/14/2003 12:42
>
>
> AM
>
>
>
>
>
>
>
>
> Yes, I understand. My concern is the case where not
> everything is under
> my control. In this particular case, all DLLs are ours, but
> imagine that
> some of them are not - how would I know if Xalan was
> initialized by some
> other DLL or not (I speak of DLLs because sometimes they come without
> source code so you can't know what's inside).
>
> Nevertheless, if you say that leak is small (negligible) that is good
> enough for me.
>
> Thanks,
>
> Drazen
>
> > -----Original Message-----
> > From: David N Bertoni/Cambridge/IBM
> > [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, March 13, 2003 5:58 PM
> > To: [email protected]
> > Subject: Re: Xalan initalization
> >
> >
> >
> >
> >
> >
> > Hi Drazen,
> >
> > The reason the "counting" strategy that Xerces uses is not
> > implemented in
> > Xalan is because it's _not_ thread safe, even though users
> > seem convinced
> > it is. This catches people frequently, and causes many more
> > problems than
> > it solves.
> >
> > Yes, if you call XalanTransformer::initialize() multiple
> > times, it will
> > happily re-initialize, and leak a bit, but I believe that is
> > well-documented. We could add a member function to call to
> > test if the
> > library is initialized, but that has the same problem as any
> > other strategy
> > -- it's not thread-safe but some users will think it is, no
> > matter what we
> > say.
> >
> > So, as far as I'm concerned, this really _is_ a user-level
> > problem, not one
> > of the library. There are many ways to implement this
> > cleanly and safely
> > at the user level and not one at the library level.
> >
> > Dave
> >
> >
> >
> >
> >
> >
> > "Drazen DOTLIC"
> >
> >
> > <[EMAIL PROTECTED] To:
> > <[email protected]>
> >
> > rema.com> cc: (bcc:
> > David N Bertoni/Cambridge/IBM)
> >
> > Subject: Xalan
> > initalization
> >
> > 03/13/2003 04:00
> >
> >
> > AM
> >
> >
> >
> >
> >
> >
> >
> >
> > Hello,
> >
> > I have a strange case where I have several DLLs being loaded to a
> > process, and some of them need Xerces/Xalan initialization
> > performed in
> > order to use the Xerces/Xalan code. Now, I cannot tell if the
> > initialization has been performed (I found no way at least)
> when "my"
> > DLL loads because there might be some other DLL loaded
> before me that
> > did the same thing, so I must initialize again (potentially for the
> > second or third time). This does not look harmless - even
> though that
> > documentation claims that this is possible and only slightly
> > inefficient
> > (in this scenario it is for sure thread safe). Xerces initialization
> > guards itself from multiple initializations, but Xalan does
> > not, blindly
> > allocating (at least one) object and storing a pointer to the same
> > global variable, over and over again. I don't see how we can avoid
> > memory leaks here? Why isn't there in place any kind of
> guard (similar
> > to Xerces) - I know it would not be thread safe, but at
> least is works
> > in scenarios like this one?
> >
> > I know I can enforce this myself, adding another level of
> indirection
> > (all problems can be solved by adding levels of indirection
> > :)) ) but I
> > was just wandering if I missed something or if the
> > documentation has to
> > be amended...
> >
> > Thanks,
> >
> > Drazen
> >
> >
> >
>
>
>
