On Wed, Apr 20, 2005 at 10:41:24AM -0700, Tim Rowledge wrote:
> "Bruce O'Neel" <edoneel at sdf.lonestar.org> wrote:
> 
> > On Wed, Apr 20, 2005 at 09:04:45PM +1200, Michael van der Gulik wrote:
> > 
> > > Be carefull not to modify any code from any of those headless instances 
> > > - the squeak.sources file will end up corrupted. There is no 
> > > multi-threaded protection on it. (I learned this the hard way.)
> > > 
> > 
> > I would expect the .sources file to be read/only.
> It's certainly supposed to be. It is opened as readonly in FileDirectory
> class>openSources:forImage: So there shouldn't be any mangling of the suorce
> file...
> 
> >  The .changes file
> > on the other hand gets quite messed up when you have multiple
> > instances pounding on the same .changes file.
> Exactly. It is of neccessity opened read/write (several times in fact, as I
> used to complain of regularly) an nominally the logging of changes is done by
> seekign to the end of the file and writing. This does no good if two or more
> writing processes are going on at the same time (see, I managed to link it to
> the native threads thread!) you get the classic problem of shared resources.
> 
> I think it is pretty obvious that in any production use of a developed
> application that there would not be much of as problem with the changes file;
> lots of other parallel issues would be driving you to hairlessness before that
> one got noticed.

Hmmm, this branch of the thread had to do with forking a herd of Squeaks
using OSProcess. It would obviously not be a good idea to have all those
Squeak children scribbling on the same changes file for the reasons
stated here (and some other obvious reasons as well, like it just makes
no sense). But if you really wanted to let this happen, OSProcess also
provides file locking and you could certainly add changes file locking
if you wanted to.

There are about 25 references to "SourceFiles at: 2" in Squeak, along
with 3 references to "SourceFiles last", and no doubt a few other
references that I didn't think to look for. So adding changes file
locking would take some work to get right.

A simpler and more sensible strategy is to arrange for the child
Squeaks to stop writing to the changes file. This is the same thing
you need in order to run Squeak from a CDROM, and ideally would be
controlled by a single preference. That would be useful for folks
who want to run Squeak from CDROM (lots of people) as well as for
folks who want to run lots of child Squeaks on big multiprocessor
systems (probably nobody ;-).

Dave