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



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.

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.

-- 
Peter Jones <unix;c++;crypto;xml;vi;4wd;geek> [ http://pmade.org ]
PGP Fingerprint: 0A2B F8AB 63CF F7A2 556F F892 5B43 7370 A4B6 E0DF



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]