Hi Wolfgang, (I'm replying to the list, instead of you directly.)
> Hi Dave! > > > We don't want to implement a counter, because that gives the false > > assumption that initialization is thread-safe and applications can do it > > willy-nilly with no problem. > > OK, that's sounds quite reasonable. > > > You could also make your functions thread-safe, if you > > need to. My feeling is that this sort of thing is more appropriate at > > the application -level than at the library level. > > The problem is that by using a library of Xalans size it's not exactly easy > to figure out, which parts are thread safe and which parts are not without > taking a closer look at the source code (which takes quite some time...). > > So why not implementing usage counters etc. with the possibility to plug in > a user supplied thread locker object (e.g. using templates, ...) whereever > needed? The library developers usually know much better, which parts have to be > protected against concurrent access. I could then decide to write a single > threaded application with a dummy locker or provide a suitable locking > mechanism for my threading platform (Win32 threads, pthreads, Solaris threads, > ...). Of course that would probably lead to quite some code changes, so just > regard this as an idea for further improvement... We've actually imposed a very simple set of thread-safety policies with Xalan. There is a FAQ, and there should be details about thread-safety noted in the public interfaces. If not, we'll be sure to update the documentation accordingly. But let me summarize: 1. Initialization/termination is not thread-safe and must be called only once per process. 2. Source documents and stylesheets, once parsed, are read-only, and therefore may be shared amongst threads. 3. All other instance objects in Xalan are not thread-safe. Xalan does _no_ explicit synchronization, period. The only implicit synchronization is that performed by Xerces, by calls to C/C++ run-time library functions, or by calls to platform-specific functions. I suppose we could have some sort of "plug-in" synchronization, but it would require a fair amount of code changes, and I'm not sure what the win would be. I'd rather limit the need for Xalan to rely on synchronization and improve the documentation so users are properly informed. > > Why can't you implement your own counter mechanism, if that's what works > > for your application? > > I'll probably do this. > > > > However, it's no mystery which version you're using. We tag all of the > > files when we do a release, and also leave the CVS directories in the > > distribution, so you should have no problem with CVS access using the > > source tree in the distribution. (We use anoncvs to pull down the source > > trees for the builds) > > I sit behind a firewall so access to the CVS server is not an option here > :-( I use SocksCap with WinCVS on my Windows machine and it works link a charm. I also use socks on a Linux box and command line CVS as well. As long as you have a socks server available, you should have no problem as well. If you don't have a socks server, then you can discover the version of a particular file by consulting the CVS control files. Just take a look at the Entries files in each CVS subdirectory. Dave
