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 > > > > > > > > >
