Thanks for the contribution.

IMO partial refactoring of ActiveThreadPool (and related classes) to have a single task queue in the pool where the threads take the work from would automatically create optimal load-balancing and simplify the implementation at the same time.

Thanks for the contribution.

IMO partial refactoring of ActiveThreadPool (and related classes) to have a single task queue in the pool where the threads take the work from would automatically create optimal load-balancing and simplify the implementation at the same time.

Hi!
I thougt about it. If notificationqueue was lock-free than you proposition shoud be correct. In our case realisation with single queue would contains many locks and bad performance.
May be flat combinig implementation is better choise for us...

This change appears to fail with the Thread Sanitizer. The actual log has much more in it https://github.com/pocoproject/poco/actions/runs/8982526627/job/24670333088?pr=4548.

testActiveThreadLoadBalancing: ==================
WARNING: ThreadSanitizer: data race (pid=33153)
  Read of size 8 at 0x7ffe63aa0b60 by thread T16:
    #0 Poco::ActiveThread::run() <null> (libPocoFoundation.so.103+0xf9197)
    #1 <null> <null> (libPocoFoundation.so.103+0x1cc80e)
    #2 Poco::ThreadImpl::runnableEntry(void*) <null> (libPocoFoundation.so.103+0x1cdebd)

@bas524 Does the PR #4624 with different implementation that was merged to main satisfy the needs?

@bas524 Does the PR #4624 with different implementation that was merged to main satisfy the needs?

Hi, I'll check it next week

@bas524 Does the PR #4624 with different implementation that was merged to main satisfy the needs?

@matejk
I answered into #4624 (comment)