|Anonymous | Login||08-11-2020 22:47 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0007032||[Squeak] System||major||always||04-28-08 18:44||04-28-08 19:16|
|Summary||0007032: RemoteString>>#text needs to be thread-safe|
There is a race condition (read after seek) if two processes try to access the sourcecode for the same method concurrently.
It can be reproduced using:
[1000000 timesRepeat: [Categorizer class sourceCodeAt: #allCategory]] forkAt: 30.
and then opening a ProcessBrowser.
Since each RemoteString is created as a new instance, an InstanceVariable lock wouldn't do it. Neither a class variable lock as the debugger might want to access a method while the lock is being held.
Thanks to RandalSchwartz on IRC for helping to nail down the problem.
(0012045 - 686 - 728 - 728 - 728 - 728 - 728)
phb - the problem is not with RemoteString. To fix it, we need a file streams protected by mutex (SourceFiles global var).
So, if we going to fix that, we need these streams protected from concurrent access.
Too bad, SourceFiles used in many places , since its global var
I'd prefer to introduce something like SourceControl, with own protocol to read/add sources or search.. and get rid of a SourceFiles global.
in my image, i have 55 references to SourceFiles.. including from Installer, MC, ChangeList.. looks like a major refactoring work
so, the only way, how i see it now, is just avoid using SourceFiles concurrently until someone will came up with major refactoring :)
|04-28-08 18:44||phb||New Issue|
|04-28-08 19:16||sig||Note Added: 0012045|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
32 total queries executed.|
27 unique queries executed.