Squeaksource (in)stability
Andreas Raab
andreas.raab at gmx.de
Tue Oct 2 20:44:14 UTC 2007
Hi Lukas -
Let's leave the storage alone for a second, what I'm really curious
about is how Squeaksource protects against concurrent modifications. I
don't know all that much about Seaside but as far as I know Seaside
doesn't have any builtin mechanism to deal with serialization of
concurrent requests and there doesn't seem to be any request
serialization in SSRepository that I can see. So how exactly does this work?
My big suspicion is that the SSFileRepository>>saveRepository: interacts
with concurrent modifications of that very same repository. That
suspicion is mostly due to:
* me not understanding how Seaside / Squeaksource protect against
concurrent modifications internally
* the singular use of a single critical section for saves only (!)
* the priority of the save being lower than normal which ensures that
(unless there are other means of synchronization that I am not aware of)
any request that comes in during the save *will* concurrently modify the
repository being written.
I don't think any of this has to do with Semaphore or Delay issues
(although these issues certainly don't help the situation); it's just
plain concurrency issues.
Cheers,
- Andreas
Lukas Renggli wrote:
> www.squeaksource.com has almost 1000 projects with more than 25000 versions.
>
> It works without problems for years now. The only issue we recently
> had could be fixed by loading the Semaphore patches of Andreas.
>
> The image storage works very reliable, we never had a problem with that.
>
> Lukas
>
More information about the Squeak-dev
mailing list
|