-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DeferredUIMessages queue occassionally locked #116
Comments
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: ***@***.***>
|
Over the past few years, I have observed the following behavior a couple of times: In
WorldState
, theDeferredUIMessages
SharedQueue
keeps non-empty permanently, and sendingnextOrNil
to it always answersnil
. 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?The text was updated successfully, but these errors were encountered: