On Tue, Jan 20, 2015 at 2:22 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
> 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...
>

Maybe.  And Tim's point about the file api is well0-taken, but its much
more work at the Smalltalk level than at the VM level.

However, I still want to see evidence of the potential thread-safety
issues.  Access to the source files for writing is not thread-safe anyway
but no one complains about that.  So I suspect we may be trying to fix a
problem that doesn't really exist.  IMO it is much more preferable to have
fast access to source than thread-safety.  If someone wants thread-safe
access they can roll their own solution (e.g. install a wrapper hiding a
mutex around the source files).  The common case of accessing source should
be fast.  The difference between

    self systemNavigation allSelect: [:m| m getSourceFromFile asString
includesSubString: 'not likely']

and

    CurrentReadOnlySourceFiles cacheDuring: [self systemNavigation
allSelect: [:m| m getSourceFromFile asString includesSubString: 'not
likely']]

is 34 to 1 (!!), 28 seconds vs 0.8.

:-(


>>> 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
>>
>>
>>
>>
>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150120/5b654a92/attachment.htm