[squeak-dev] CurrenReadOnlySourceFiles (was: Re: Question about inlining | How to access named temps in FullBlockClosure?)

Levente Uzonyi leves at caesar.elte.hu
Tue Mar 31 22:31:04 UTC 2020

Hi Eliot,

On Mon, 30 Mar 2020, Eliot Miranda wrote:

> Hi Levente,
>> On Mar 30, 2020, at 2:21 PM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>> Hi Eliot,
>>> On Mon, 30 Mar 2020, Eliot Miranda wrote:
>>> Well, that's not what I meant by a search.  However, as Levente pointed out, textual searches should be surrounded with CurrentReadOlySouceFiles cacheDuring:.  I think this is an awful implementation and would implement it
>>> very differently but that's the work-around we have in place now,
>> How would you implement it?
>> <history>
>> When I introduced CurrentReadOnlySourceFiles, I wanted to solve the issue of concurrent access to the source files.
>> I had the following options:
>> 1) controlled access to a shared resource (a single read-only copy of the SourceFiles array) with e.g. a Monitor
>> 2) same as 1) but with multiple copies pooled
>> 3) exceptions to define the scope and lifetime of the resources (the read-only copies) within a process
>> I chose the third option because it was possible to introduce it without exploring and rewriting existing users: you could leave all code as-is
>> and sprinke CurrentReadOnlySourceFiles cacheDuring: [ ... ] around code that needed better performance.
>> It's obviously not a perfect solution, but I still think it was the best available at the time.
>> Later ProcessLocalVariables were added to Trunk. Which could be used to solve the concurrent access issue by using process-local copies of the source files. The only challenge is to release them after they are not needed any more. Perhaps a high priority process could do that after a few minutes of inactivity. Or we could just let them linger and see if they cause any problems.
>> </history>
> I think the key issue (& this from a discussion here with Bert) is access time source in the debugger while one is debugging file access.  As the debugger asks for source so the file pointer is moved and hence screws up the access one is trying to debug.

I don't think that's the only issue. Have a look at the senders of 
#readOnlyCopy. Many of them were added 10+ years ago, well before 
CurrentReadOnlySourceFiles was introduced. Most of those could use 
CurrentReadOnlySourceFiles too but are unrelated to the debugger.

> So I would provide something like
>   SourceFiles withSubstituteCopiesWhile: aBlock
> which would install either copies of the files or read-only copies of the files for the duration of the block, and have the debugger use the method around its access to method source.
> The IDE is essentially single threaded as far as code modification goes, even if this isn’t enforced. There is no serialization on adding/removing methods and concurrent access can corrupt method dictionaries, and that limitation is fine in practice.  So having the same restriction on source file access is fine too (and in fact I think the restriction already applies; if one were to fork compiles then source update to the changes file could get corrupted too).
> So I think not using read-only copies to read source, and having the debugger use copies for its access would be a good lightweight solution.

I agree with what you wrote about method changes, but reading the sources 
concurrently is still a possibility, especially when multiple UI processes 
can exist at the same time (e.g. that's what opening a debugger does, 


>> Levente
> Eliot

More information about the Squeak-dev mailing list