DeferredUIMessages queue occassionally locked #116
Labels
bug
[WHAT] Something isn't working as expected. Automated tests beneficial. :-
Comments
LinqLover
added
the
bug
|
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 You can also signal Maybe this is the reason, |
|
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: ***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Over the past few years, I have observed the following behavior a couple of times: In
WorldState, theDeferredUIMessagesSharedQueuekeeps non-empty permanently, and sendingnextOrNilto it always answersnil. Practically, this causes UI messages being handled a few ticks too late, or even never. In this situations,readSynchapparently has not been signaled often enough. I have however no idea how this situation arises, nor I could reproduce it ... possibly some concurrency issue?The text was updated successfully, but these errors were encountered: