Re: [xslt] "libxslt with thread-enabled libxml2?"

[Igor Zlatkovic <igor zlatkovic com>]

On Fri, Apr 11, 2003 at 12:50:01PM -0700, Peter Jones wrote:
> Hey, remember back when Daniel Veillard said:
> > I expect to switch libxml2 compilation to be thread aware on Linux 
> 
> Maybe I am missing something here, but why does libxslt need to be
> "thread aware"?
> 
> I should point out my definition of thread aware, vs. thread safe.
> 
> Thread aware is when the library detects that it is being used in a
> multithreaded application and uses things like mutexes to protect parts
> of the library that are not thread safe.
> 
> Thread safe is when the library does not care if the application is
> multithreaded or not. It does not use things such as global variables,
> or function static variables. There is no need to use mutexes or
> anything else related to threads.

Unfortunately, there are global variables and breaking the binary
compatibility by removing them would break a half of the world. Neither
GNOME nor KDE desktops would work. The impact would be unbearable.

> Now, maybe we are talking about some of the libxslt callbacks. If I
> wanted to write an XPath extension function I would need to give libxslt
> a callback function.
> 
> If libxslt was tread aware, it would lock some mutex before it called my
> callback (maybe). If it was thread safe, it would allow me to use a
> context pointer that gets passed to the callback, and the callback would
> decide whether or not a mutex needs to be locked.
> 
> It is definitely a matter of opinion and preference, but I don't think
> libxslt should be thread aware, just thread safe. The bonus of thread
> safety, is it usually yields a better design, e.g. no global variables.

All fine, but its an utopia. libxml2 must remain functional when used
with things which are allready compiled. 

I agree, variables should never be exported from a library, functions
for their manipulation should be exported instead. The contents of
internal structures should never be revealed to the application, apps
should use pointers to these as opaque handles instead. This gives more
work at the API and takes some flexibility, but makes it possible never
to break source or binary compatibility.

This is not where we are. Libxml wasn't designed yesterday, it exists
for quite a few years now. Its designers began long ago, never dreaming
about all the problems and oddities multiple platforms would bring.
Today, libxml and libxslt are not just about to be released, but present
the very base for the most of what people see on their screen.

It is not the matter of preference. Now the art of programming is asked
for. And the art is not to produce the code for another programmer to
admire its design. The art is to produce executables which ease the life
of the end-user and make her cry for more :-)

Ciao,
Igor