<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 3:29 PM, tim Rowledge <span dir="ltr">&lt;<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
&gt; On 16-12-2015, at 2:43 PM, Levente Uzonyi &lt;<a href="mailto:leves@caesar.elte.hu">leves@caesar.elte.hu</a>&gt; wrote:<br>
&gt;<br>
&gt; My objection is that concurrent access of the read-only source files would cause race conditions.<br>
&gt; We might simplify the thing by using the regular source files (or some shared read-only copies) when requested from the UI process, and create a read-only copy for all other processes. That would cover most potential slow-downs in the Trunk.<br>
<br>
</span>One of the best ways to avoid file read (and many write) issues would be to get rid of the {deletable expletive} stupid separate move &amp; read/write operations. If the primitive were readBytes: num from: file to: buffer at: startposition and so on a lot of problems could not exist. It’s like error codes being found via a distinct api instead of being returned directly - a catastrophe waiting to happen.<br></blockquote><div><br></div><div>Agreed.  How do we make this so?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
This is all a lot simpler and a lot more complicated than you could possibly imagine<br>
<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>