2010/9/3 Daniel P. Berrange <berrange(a)redhat.com>:
On Fri, Sep 03, 2010 at 01:02:09PM +0200, Matthias Bolte wrote:
> Ah, okay, now I understand what you want to say.
>
> You have two threads A and B. When A runs on its own then it's just
> fine, but when you add B (that triggers an exception on purpose and
> ignores it) then A picks it up and reports it. This is the point where
> thread safety comes to mind.
>
> libvirt stores errors in thread-local-storage. It uses
> pthread_key_create/pthread_{get,set}specific for this (or
> TlsAlloc/Tls{Get,Set}Value on Windows).
>
> I think what's happening here is that all your threads in Java share
> the same thread-local-storage. Therefore, thread A can pickup the
> error triggered by thread B, that should not happen.
That could only happen if the JVM was using green threads instead of
native threads, but no serious JVM still uses green threads these days.
Well, yes. That's what I thought too and that's why it took me a while
until I understood what he meant.
But I can reproduce it his test program and with latest libvirt and
libvirt-java and the default JVM here on Ubuntu 10.04:
$ java -version
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.1) (6b18-1.8.1-0ubuntu1)
OpenJDK 64-Bit Server VM (build 16.0-b13, mixed mode)
I get stacktraces printed from TestMultiThreadingLibvirt for
exceptions that are actually triggered in
TestMultiThreadingLibvirtWithError in another thread.
Matthias