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<mailto: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<mailto:pharo-project-boun...@lists.gforge.inria.fr>
 
[pharo-project-boun...@lists.gforge.inria.fr<mailto:pharo-project-boun...@lists.gforge.inria.fr>]
 de la part de Henrik Johansen 
[henrik.s.johan...@veloxit.no<mailto:henrik.s.johan...@veloxit.no>]
Date d'envoi : lundi 29 avril 2013 11:54
À : 
Pharo-project@lists.gforge.inria.fr<mailto: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


Reply via email to