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.goubier@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-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] de la part de Nicolas Cellier [nicolas.cellier.aka.nice@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.goubier@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-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] de la part de Henrik Johansen [henrik.s.johansen@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