DeferredUIMessages queue occassionally locked

[LinqLover]

Over the past few years, I have observed the following behavior a couple of times: In WorldState, the DeferredUIMessages SharedQueue keeps non-empty permanently, and sending nextOrNil to it always answers nil. Practically, this causes UI messages being handled a few ticks too late, or even never. In this situations, readSynch apparently has not been signaled often enough. I have however no idea how this situation arises, nor I could reproduce it ... possibly some concurrency issue?

[marceltaeumel]

If you suspect that the two semaphores guarding deferred UI messages got somehow broken in your image, try resetting the entire queue:

DeferredUIMessages := SharedQueue new.

Do-it in a regular code browser on WorldState.

You can also signal readSynch manually if it seems one off. Not sure how this might have happened. Looking at SharedQueue >> #nextPut: ... maybe if there is an interrupt before readSynch signal? From [CMD]+[.] maybe?

Maybe this is the reason, SharedQueue2 exists? More robust? Levente might know more.

[squeak-smalltalk-bot]

If you suspect that the two semaphores guarding deferred UI messages got somehow broken in your image, try resetting the entire queue: ​DeferredUIMessages := SharedQueue new. Do-it in a regular code browser on WorldState.

Ah, I should have mentioned that. Yes, this is my current workaround ... unfortunately testing with a SharedQueue2 will not yield significant results given the extremely low occurrence rate of this issue ...

…

________________________________ Von: Marcel Taeumel via Squeak-dev ***@***.***> Gesendet: Montag, 19. Februar 2024 15:09 Uhr An: squeak-smalltalk/squeak-object-memory ***@***.***> Cc: Subscribed ***@***.***>; Marcel Taeumel ***@***.***> Betreff: [squeak-dev] Re: [squeak-smalltalk/squeak-object-memory] DeferredUIMessages queue occassionally locked (Issue #116) If you suspect that the two semaphores guarding deferred UI messages got somehow broken in your image, try resetting the entire queue: DeferredUIMessages := SharedQueue new. Do-it in a regular code browser on WorldState. You can also signal readSynch manually if it seems one off. Not sure how this might have happened. Looking at SharedQueue >> #nextPut: ... maybe if there is an interrupt before readSynch signal? From [CMD]+[.] maybe? Maybe this is the reason, SharedQueue2 exists? More robust? Levente might know more. — Reply to this email directly, view it on GitHub<#116 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BFYAK6IQYWRUENIGXD4YOVDYUNMH3AVCNFSM6AAAAABDONSRZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJSGUZDQNRTGY>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>