<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 20, 2015 at 2:22 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2015-01-20 2:18 GMT+01:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Jan 19, 2015 at 5:09 PM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@elte.hu" target="_blank">leves@elte.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Mon, 19 Jan 2015, Eliot Miranda wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
On Mon, Jan 19, 2015 at 1:31 PM, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@<u></u>gmail.com</a>> wrote:<br>
Hi Tobias,<br>
are you aware of CurrentReadOnlySourceFiles cacheDuring: [...]<br>
This is to workaround the readOnlyCopy used for thread safety which is the main killer of performance...<br>
<br>
<br>
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<br>
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<br>
accesses source is huge. And CurrentReadOnlySourceFiles cacheDuring: [...] is a /lot/ of verbiage to type in doits, and a sign that something is wrong.<br>
</blockquote>
<br>
How would using a single copy solve the concurrency issues?<br></blockquote><div><br></div></span><div>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?</div><span><div> </div></span></div></div></div></blockquote><div><br></div></span><div>Couldn't there be a difference because VW properly handle read-append-stream for the underlying FILE?<br></div><div>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...<br></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div> self systemNavigation allSelect: [:m| m getSourceFromFile asString includesSubString: 'not likely']</div><div><br></div><div>and</div><div><br></div><div> CurrentReadOnlySourceFiles cacheDuring: [self systemNavigation allSelect: [:m| m getSourceFromFile asString includesSubString: 'not likely']]<br></div><div><br></div><div>is 34 to 1 (!!), 28 seconds vs 0.8.</div><div><br></div><div>:-(</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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.</blockquote><div><br></div></span><div>If concurrent access was really an issue then OK. But first I'd like some evidence that there's a real problem here.</div></div><span><font color="#888888">-- <br><div>best,<div>Eliot</div></div>
</font></span></div></div>
<br><br>
<br></blockquote></span></div><br></div></div>
<br><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>