Christoph Thiede uploaded a new version of Collections to project The Inbox: http://source.squeak.org/inbox/Collections-ct.1063.mcz
==================== Summary ====================
Name: Collections-ct.1063 Author: ct Time: 2 March 2024, 6:08:41.266276 pm UUID: e5cc1f5c-62e6-3d4a-81f0-e8de89f894c4 Ancestors: Collections-mt.1058
Fixes WeakSet>>removeAllSuchThat: for GCs during removal. Please review.
=============== Diff against Collections-mt.1058 ===============
Item was added: + ----- Method: WeakSet>>removeAllSuchThat: (in category 'removing') ----- + removeAllSuchThat: aBlock + "Overridden to avoid NotFound errors when elements where garbage-collected between selection and attempt to removal." + + self copy do: [:each | (aBlock value: each) ifTrue: [self remove: each ifAbsent: []]]!
Hi Christoph,
Can you explain the scenario this change fixes?
Best, Levente
On 2024. 03. 02. 17:08, commits@source.squeak.org wrote:
Christoph Thiede uploaded a new version of Collections to project The Inbox: http://source.squeak.org/inbox/Collections-ct.1063.mcz
==================== Summary ====================
Name: Collections-ct.1063 Author: ct Time: 2 March 2024, 6:08:41.266276 pm UUID: e5cc1f5c-62e6-3d4a-81f0-e8de89f894c4 Ancestors: Collections-mt.1058
Fixes WeakSet>>removeAllSuchThat: for GCs during removal. Please review.
=============== Diff against Collections-mt.1058 ===============
Item was added:
- ----- Method: WeakSet>>removeAllSuchThat: (in category 'removing') -----
- removeAllSuchThat: aBlock
- "Overridden to avoid NotFound errors when elements where garbage-collected between selection and attempt to removal."
- self copy do: [:each | (aBlock value: each) ifTrue: [self remove: each ifAbsent: []]]!
Hi Levente,
I wish I could! I can tell you that I have seen a NotFound error signaled from WeakSet(Collection)>>removeAllSuchThat: while cleaning up a WeakSet of processes in the background:
processes removeAllSuchThat: [:ea | ea terminate. true].
Unfortunately, I was not able to reproduce this again ... I just debugged the above example again and it seems that each element is indeed strongly referenced from the activation of the block closure up to its removal. Maybe, I was facing a concurrency issue (multiple #removeAllSuchThat: sends from different processes at the same time) instead. In that case, I fear I would have to use a Mutex because none of the removal methods are concurrency-safe, right?
Best, Christoph ________________________________ Von: leves leves@caesar.elte.hu Gesendet: Montag, 4. März 2024 15:13 Uhr An: squeak-dev@lists.squeakfoundation.org squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] Re: The Inbox: Collections-ct.1063.mcz
Hi Christoph,
Can you explain the scenario this change fixes?
Best, Levente
On 2024. 03. 02. 17:08, commits@source.squeak.org wrote:
Christoph Thiede uploaded a new version of Collections to project The Inbox: http://source.squeak.org/inbox/Collections-ct.1063.mcz
==================== Summary ====================
Name: Collections-ct.1063 Author: ct Time: 2 March 2024, 6:08:41.266276 pm UUID: e5cc1f5c-62e6-3d4a-81f0-e8de89f894c4 Ancestors: Collections-mt.1058
Fixes WeakSet>>removeAllSuchThat: for GCs during removal. Please review.
=============== Diff against Collections-mt.1058 ===============
Item was added:
- ----- Method: WeakSet>>removeAllSuchThat: (in category 'removing') -----
- removeAllSuchThat: aBlock
"Overridden to avoid NotFound errors when elements where garbage-collected between selection and attempt to removal."
self copy do: [:each | (aBlock value: each) ifTrue: [self remove: each ifAbsent: []]]!
Hi Christoph,
On 2024. 03. 04. 16:19, Thiede, Christoph wrote:
Hi Levente,
I wish I could! I can tell you that I have seen a NotFound error signaled from WeakSet(Collection)>>removeAllSuchThat: while cleaning up a WeakSet of processes in the background:
processes removeAllSuchThat: [:ea|eaterminate. true].
Unfortunately, I was not able to reproduce this again ... I just debugged the above example again and it seems that each element is indeed strongly referenced from the activation of the block closure up to its removal. Maybe, I was facing a concurrency issue (multiple #removeAllSuchThat: sends from different processes at the same time) instead. In that case, I fear I would have to use a Mutex because none of the removal methods are concurrency-safe, right?
I'm pretty sure it was a side effect of concurrent access. HashedCollections are not thread-safe by default. I think, with the current implementations, it's safe to read them concurrently, but I wouldn't rely on that. So, yes, you need to use a Mutex, a Semaphore, a Monitor, or some priority hacking to avoid concurrent access.
Best, Levente
squeak-dev@lists.squeakfoundation.org