On Wed, Dec 16, 2015 at 06:49:20PM -0800, Eliot Miranda wrote:
> Hi Levente,
> 
> On Wed, Dec 16, 2015 at 2:43 PM, Levente Uzonyi <leves at caesar.elte.hu>
> wrote:
> 
> > My objection is that concurrent access of the read-only source files would
> > cause race conditions.
> > 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.
> 
> 
> Apart form the debugger can you think of situations in which this will
> really happen?  I can't. If you can convince me that concurrent access is a
> real danger then I'll think again, but in all my time doing Smalltalk with
> Smalltalk-80 v2, with VisualWorks and with Croquet, Squeak and Pharo the
> only time this has been an issue was in the debugger debugging source file
> access.  Given that that's easy to solve I don't see the point of living
> with such slow source file access for any longer :-)
> 

The CurrentReadOnlySourceFiles changes were added in March 2011 in
Files-ul.104 and Files-ul.105. I do not recall the specific problems that
motivated this change, but they were real problems and I don't think that
it was anything related to the debugger. Levente can probably refresh
our collective memory but I think that it may have been something related
to running SUnit tests or the MC update stream processing.

Be that as it may, it seems to me that accessing source files entries
is a fundamental thing that needs to work reliably in a multi-process
environment, period (*).

Dave

(*) I was tempted to say "without exception" rather that "period", but
that would imply an implementation bias ;-)