Yes, you are right with current implementation. But if changes is not a code repository anymore, there is no need to record the position. So if we open in mode 'a' or 'a+', we could be back to an atomic primitive operation (if the primitive is blocking and can't fail/retry - which would be another option for async IO).
If reading is restricted to recovery tool, the whole need for state-sharing-via-file will vanish. A readOnlyCopy/flush pair would perfectly work in this restricted case. The flush could eventually be triggered by the recovery tool itself. 2013/4/30 GOUBIER Thierry <thierry.goub...@cea.fr> > Not so sure. Even with un-interruptible primitives, the RemoteString is > wrong. > > It should be something like write chunk in a lock, return chunk final > position once done. Then the RemoteString instance can compute the start > position and store it. No more race condition for that one. > > An, for anything which takes a readOnlyCopy, try to flush the RW one > before (or just remove that optimisation of opening multiple streams; > anything which tries to do data sharing via external files is asking for > trouble). > > Thierry > > > ------------------------------ > *De :* pharo-project-boun...@lists.gforge.inria.fr [ > pharo-project-boun...@lists.gforge.inria.fr] de la part de Nicolas > Cellier [nicolas.cellier.aka.n...@gmail.com] > *Date d'envoi :* mardi 30 avril 2013 11:24 > *À :* Pharo Development > *Objet :* Re: [Pharo-project] RE : cannot modify class comments on Linux > > I think this was written with write once, read many restriction... > However, > - If the write stream would just append and not mess with position: > - And if the whole chunk was written in a single primitive call, > Then the write could still be safe, because primitive are currently > un-interruptible. > Otherwise, as for every shared ressource, proper locking should be used... > > But let's not do it: > Indeed, if the changes is no more a code repository, but just becomes a > failsafe change log, then we don't need anymore to log the content of code > we import (with MC or fileIn or other means...). > Logging the root action should be enough (MCLoaderOrSomething > loadFromURL: '....'!). > Thus, there would be no need for background logging, only the UI process > would log things and thus the write once model would be simple enough. > So, IMO, it's not usefull to waste cycles on something complex here. > Thoughts? > > Nicolas > > > 2013/4/30 GOUBIER Thierry <thierry.goub...@cea.fr> > >> I confirm, it's 1) >> >> Adding a flush just before reopening the file R-O for the RemoteString >> instance solves this problem. However, this isn't obvious (i.e. the R-O >> opening is lazily triggered by another RemoteString method). >> >> I don't like, from a threading point of view, the RemoteString writing >> code. It takes the stream position before writing stuff in it, opening an >> opportunity window for a race condition. >> >> Thierry >> >> ________________________________________ >> De : pharo-project-boun...@lists.gforge.inria.fr [ >> pharo-project-boun...@lists.gforge.inria.fr] de la part de Henrik >> Johansen [henrik.s.johan...@veloxit.no] >> Date d'envoi : lundi 29 avril 2013 11:54 >> À : Pharo-project@lists.gforge.inria.fr >> Objet : Re: [Pharo-project] cannot modify class comments on Linux >> >> On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote: >> >> > To be perfectly clear, does the bug occurs >> > 1) because we open a new file descriptor for read without flushing the >> old one for write, >> > 2) or does it occur with a single file descriptor opened 'rw' ? >> > >> > If 1), then this is probably our fault. >> > If 2), then I wouldn't expect such behavior. >> >> 1), different streams are used for reading/writing, to reduce threading >> errors in relation to position usage. >> RemoteStrings have an unusual tendency to jump around a lot in the >> streams they're linked to, which is no fun if you, say, try and write new >> source at the same time in a different thread. >> >> Cheers, >> Henry >> >> >
