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