On Mon, Jan 21, 2013 at 3:21 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> How do we make that single copy thread-safe?
>

IMO the only context in which its really important that source access is
thread-safe is the debugger; one is debugging source access and the
Debugger is fetching source from methods as one is debugging, hence
screwing up the source access one is debugging.  So what if the Debugger
took care to save the readOnlyCopy's position around each source fetch and
restored it?  Wouldn't that be good enough and allow one to get away
without making it thread-safe?


> - Bert -
>
> On 21.01.2013, at 15:06, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> IMO the readOnlyCopy logic is broken.  e should modify SourceFiles to keep
> a *single* read-only copy alongside each writable copy, and supply that
> when asked for a read-only copy.  The read-only copy is effectively a
> cache.  It needs to be flushed when a source file changes and when the
> image starts up.  Again I have code for this from a modified 3.9 image if
> anyone is interested.  IMO this is important.
>
>
> On Mon, Jan 21, 2013 at 11:35 AM, Vaidotas Didžbalis <vaidasd at gmail.com>wrote:
>
>> > Seems instantaneous for me on Mac. Might be a platform issue? Which VM,
>> which OS?
>> >
>> > - Bert -
>>  Windows 7 64 bit, Cog Dec 12, 2012
>> bottleneck in method
>> CurrentReadOnlySourceFiles>>defaultAction
>> slow part is accessing changes file:
>> time to run: [SourceFiles second readOnlyCopy]  is ~ 100 ms. Caching
>> is introduced here some time after 4.1. On XP 32 bit without antivirus
>> there is no issue.. aha, perhaps this is antivirus related. Quite
>> common in corporate policy in environments today. Will try tomorrow to
>> disable antivirus and report.
>> Vaidas
>>
>>
>
>
> --
> best,
> Eliot
>
>
>
>
>
>


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