On 11-01-2013, at 1:56 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> Yes.  In an older Newspeak image I added readOnlyCopy: to SourceFilesArray so that SourceFIlesArray holds precisely one read-only copy of each source/changes file instead of creating new ones whenever needed (which can run out of file handles in error cases, as happened in a Newspeak image just yesterday). Then clients (essentially getSourceFromFile) that want to read the source use (SourceFilesArray readOnlyCopyAt: fileIndex).  The read-only files are flushed at start-up.  That completely replaces the (IMO rather clunky) CurrentReadOnlySourceFiles approach.  If this sounds good I could integrate it into 4.4, except that I' prefer to shirk the effort and give the code to someone who'd review it/polish it.

Is this the ancient and very annoying scenario where various source related files are opened many times for both read and read/write, sometimes by just copying the damn file pointer bytes? I had so many problems caused by that… Eventually I had to write an entire filing system for RISCOS to fake that out. The only reason the stupid idea was even needed was the plain broken file access policy of using - what is it called, 'streams' ? - that assume the file pointer hasn't been moved when writing. It could all go away by using an api like write(toFile, thisStuff, atThispoint, thisManyBytes) instead.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: FCE: Fill Core with Epoxy