AbstractConnection.changeThreadCount() is fragile about dbus-java HOT 5 CLOSED

BTW: It's a great idea to remove the native code. It crashes the VM on ARM and Mac from time to time. ;)

from dbus-java.

I've implemented your suggestions.
The check for newcount vs. THREADCOUNT is nonsense ... It would always do nothing when the default thread count is used.

I changed it so it compares the new value vs. the max thread count of the current ExecutorService.

from dbus-java.

Thanks 👍

from dbus-java.

Unfortunately this fix did not solve the issue because the methods of the ExecutorService itself are of course not protected. I created a pull request (#60) that uses read/write locking on the thread pool.

With the new fix I did not have the problem anymore.

from dbus-java.

It would be nice to be able to set the thread pool count before connecting. Now we have to get a default-sized thread pool and once the connection is created it can be resized to 1.

Having the thread pool of size 1 is the only way, as far as I know, to make sure the signals are delivered in the correct order, which might be important for some applications.

from dbus-java.