Read-only source files (was: Re: [squeak-dev] Why is source code always in files only?)

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Jan 20 10:22:08 UTC 2015


2015-01-20 2:18 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:

>
>
> On Mon, Jan 19, 2015 at 5:09 PM, Levente Uzonyi <leves at elte.hu> wrote:
>
>> On Mon, 19 Jan 2015, Eliot Miranda wrote:
>>
>>
>>>
>>> On Mon, Jan 19, 2015 at 1:31 PM, Nicolas Cellier <
>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>       Hi Tobias,
>>>       are you aware of CurrentReadOnlySourceFiles cacheDuring: [...]
>>> This is to workaround the readOnlyCopy used for thread safety which is
>>> the main killer of performance...
>>>
>>>
>>> IMO this is a bug.  We should simply have a single read-only copy of
>>> each sources file and modify the debugger to either save and restore the
>>> state of a read-only copy around accessing source, or use its own
>>> read-only copy (except that the latter approach breaks when one debugs
>>> the debugger).  The difference in performance between using
>>> CurrentReadOnlySourceFiles cacheDuring: [...] and not in anything that
>>> accesses source is huge.  And CurrentReadOnlySourceFiles cacheDuring:
>>> [...] is a /lot/ of verbiage to type in doits, and a sign that something is
>>> wrong.
>>>
>>
>> How would using a single copy solve the concurrency issues?
>>
>
> It wouldn't, but what issues are you seeing in concurrent source access?
> VW doesn't even have read-only copies and AFAICR we never had complaints
> about this.  Is there really a thread-safety issue here?
>
>

Couldn't there be a difference because VW properly handle
read-append-stream for the underlying FILE?
I have the feeling that such FILE is more robust to single write - multiple
read concurrency, than a random-read-write FILE as used by Squeak...



>
>> I think the real solution would be to use per process copies, which were
>> initialized lazily, and were closed automatically after some time of
>> inactivity.
>
>
> If concurrent access was really an issue then OK.  But first I'd like some
> evidence that there's a real problem here.
> --
> best,
> Eliot
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150120/d1e35777/attachment.htm


More information about the Squeak-dev mailing list