[squeak-dev] CurrenReadOnlySourceFiles (was: Re: Question about inlining | How to access named temps in FullBlockClosure?)

David T. Lewis lewis at mail.msen.com
Tue Mar 31 00:05:21 UTC 2020

On Mon, Mar 30, 2020 at 03:33:09PM -0700, tim Rowledge wrote:
> > On 2020-03-30, at 2:21 PM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
> > 
> > When I introduced CurrentReadOnlySourceFiles, I wanted to solve the issue of concurrent access to the source files.
> > I had the following options:
> > 1) controlled access to a shared resource (a single read-only copy of the SourceFiles array) with e.g. a Monitor
> > 2) same as 1) but with multiple copies pooled
> > 3) exceptions to define the scope and lifetime of the resources (the read-only copies) within a process
> Without having really considered this in years, if I remember right
> almost all this problem is at root caused by the stupidity of us having
> a file access regime based on the ansi stream stuff - ie set the position,
> do a read (or write, whatever) and since they are separate operations
> one can get utterly screwed up by multiple processes having access.
> That part completely goes away with a more sensible approach where
> the position and the read/write are a single operation. As in
> readFromThisFileAcessorAtThisPositionThisManyBytes. I suspect one could
> find email from me about this from '96 at least.

I think I do recall that ancient conversation :-)

But I am a bit skeptical. After all, we are caching the file position
in StandardFileStream>>position so if there are concurrency issues,
it's not entirely obvious where the fault may lie.

How to find out? Test using a Windows VM. Andreas wrote the file primitives
for Windows to operate at the direct file HANDLE level, rather than the
higher level stdio streams that we use for the other VMs. If the original
concurrency issues go away when running on Windows, then maybe it's true
that the problem is caused by reliance on stdio streams in our non-Windows
VMs. But if the problems also exist on Windows, then the problem is more
likely right here in our own image.

If you consider the general concept of a stream over an underlying
physical storage medium, it is quite natural to think of the possibility
of multiple streams over the same underlying storage medium. That is
what stdio streams do. I am not entirely confident that we are doing
a good job of mapping that concept into StandardFileStream in Squeak.


More information about the Squeak-dev mailing list