search

squeak-smalltalk / squeak-object-memory

Issues and assets related to the Squeak object memory.
https://bugs.squeak.org
MIT License
13 stars 1 forks source link

DeferredUIMessages queue occassionally locked #116

Open LinqLover opened 7 months ago

LinqLover commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 GitHubhttps://github.com/squeak-smalltalk/squeak-object-memory/issues/116#issuecomment-1952528636, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BFYAK6IQYWRUENIGXD4YOVDYUNMH3AVCNFSM6AAAAABDONSRZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJSGUZDQNRTGY. You are receiving this because you are subscribed to this thread.Message ID: @.***>