Skip to content

ConcurrentPool should process clientCallbacks if waiting on the client#1015

Draft
RuffledPlume wants to merge 3 commits into117HD:masterfrom
RuffledPlume:ConcurrentPoolProcessClientCallbacks
Draft

ConcurrentPool should process clientCallbacks if waiting on the client#1015
RuffledPlume wants to merge 3 commits into117HD:masterfrom
RuffledPlume:ConcurrentPoolProcessClientCallbacks

Conversation

@RuffledPlume
Copy link
Contributor

Ontop of Acquire having a timeout, we not process clientCallbacks if the client is the thread currently being blocked, this is to avoid waiting when we can easily unblock the workers

Copy link
Member

@aHooder aHooder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might make sense to do anyway at some point, if we start intentionally blocking on the client thread, but I'll hold off on it for now since it effectively does nothing currently.

while ((obj = pool.poll()) == null) {
if (!parkedThreads.contains(currentThread))
parkedThreads.add(currentThread);
JobSystem.processPendingClientCallbacks();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While proof reading this, I realised that this call actually never does anything (currently). processPendingClientCallbacks exits early if it's not on the client thread, and acquireBlocking is currently only ever called from render threads in drawDynamic.

@aHooder aHooder marked this pull request as draft March 21, 2026 14:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants