Closed ghost closed 1 year ago
Thanks for reporting and explaining everything so well. I appreciate that.
But providing a PR to fix these issues would be much more appreciated.
If the PR is fine, I will simply merge it, if there is something I don't like we can discuss that.
This would spare me some time fixing all of that by myself. Even if the solution is easy, I think you should take the credit for fixing because you found the problem.
We've hooked into the D-Bus using 4.2.1 as follows:
The call to
withSignalThreadPriority
performs:That call assigns the thread priority:
The signal thread priority doesn't appear to be used because the
getSignalThreadPriority()
method isn't invoked.Within the constructor for
ReceivingService
, a newNameableThreadFactory
instance is added to the internalexecutors
map:The
ReceivingService
invokes the two-argument constructor forNameableThreadFactory
, which uses a default priority ofThread.NORM_PRIORITY
:Does the
ReceivingService
constructor need to call a differentNameableThreadFactory
constructor? That is, the one that takes the thread priority? Such as by calling_rsCfg.getSignalThreadPriority()
:Also, do we need to pass in the priority for the sending side? That is, in
AbstractConnection
:Does that need to pass
_rsCfg.getSignalThreadPriority()
as well?