Squeaksource (in)stability

Philippe Marschall philippe.marschall at gmail.com
Wed Oct 3 04:57:05 UTC 2007


2007/10/2, Lukas Renggli <renggli at gmail.com>:
> > * me not understanding how Seaside / Squeaksource protect against
> > concurrent modifications internally
>
> Seaside serializes requests for a single session. It does not
> serialize requests among multiple sessions.
>
> > * the singular use of a single critical section for saves only (!)
>
> I don't remember exactly what SqueakSource is doing. I don't have an
> image accessible right here, but maybe Philippe can comment on that?

The model itself is totally unprotected against concurrent
modifications and I'm surprised that this hasn't yet led to conflicts.
Note that the caching thread does concurrent modifications as well,
again totally unsynchronized. Gemstone has transactions so from time
to time in case of a conflict a gem falls over and is automatically
restarted.

> > * 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.

Maybe I misunderstood the Squeak process model but won't a process
waiting for IO be unscheduled anyway?

> I see, you are using the reference-stream serialization.
> www.squeaksource.com had to drop that approach after a few months,
> because it got far too slow (today it takes minutes to serialize the
> whole model).

'Took more than half an hour at ESUG.

Cheers
Philippe

> As I said, we are just saving the image.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
>



More information about the Squeak-dev mailing list