[Seaside] Are Collections threadsafe?
John M McIntosh
johnmci at smalltalkconsulting.com
Tue Feb 26 22:49:52 UTC 2008
On Feb 25, 2008, at 9:46 PM, Philippe Marschall wrote:
> Not undetected. They do show up in production. We had for example once
> a problem with a db connection pool that was protected by a Semaphore.
> Whether it worked or not depended on the priority of the thread
> accessing it. But of course implying there is something wrong with the
> VM or Image is considered heresy. If you have such issues, better just
> fix them yourself. This is easy because "the source it there" (tm). It
> was probably done intentionally so that you could expand your
> Smalltalk knowledge.
Really the problem is actually capturing meaningful data and debugging
semaphore and delay
issues is very difficult because the VM usually is catatonic at this
point. Or something is wrong
but you don't know what. There are specialized tools to do VM
message tracing or snapshots of
the squeak VM stacks outside of the image, using perhaps unfortunately
special versions of the VM
which require folks to build their own.
This is not to say we ignore things.
I'll note in the late 90's for example Dan called me and said his
squeak image hung after running for a
month. This was the first clue that macintosh operating systems had
become stable enough for you to
actually run an entire month without rebooting. Issue was millisecond
clock rollover cause event loop
processing to stop after 23+ days.
At camp smaltlalk 4 a bunch of us huddled about a table for an
afternoon trying to figure out why
Delay occasional froze, although we had no data, in the code review we
traced to an exposure between
a check for a condition and a message send that introduced an
opportunity for a higher priority task to
attempt to setup a Delay when the Delay logic was performing a
critical structure change.
Then someone say Oh they had really really long delays and that
results in large integers going into
the delay logic, yet the delay logic is dependent on the millisecond
clock which only thinks in a much smaller
number. I recall Tim spent days/weeks figuring out an optimal
solution. Noting of course tampering with
Delay on the fly, make a mistake and you get to restart your image, or
We had MC servers lock up and drive people crazy, even the Sophie team
which I am on. Someone else
finally figured out, no it wasn't a problem with unix sockets, it was
a problem in the Morphic Event loop and how
it services morphs and how it wants to ensure a 60 fps rate by real
time calculation (which I added years ago).
That prevented the servicing of MC server work threads.
Lately Andreas because he is using Squeak for qwaq pushed out quite a
number of fixed to Semaphores, are all
the issues fixed? Well you need to apply all the patches and see what
happens. So make a mantis report, we'd
like to see that thought: "Whether it worked or not depended on the
priority of the thread
> accessing it." I'm sure that would an Andreas think more about
> what is going on.
What you see now is Squeak is being much more important to people and
issues with stability cannot be
ignored or glossed over.
Shameless job plug:
Tim and I of course for a fee are quite willing to assist people who
think they have a VM issue, if your
"downtime" is costing you $$$ or causing people to think "Who picked
this crummy software?"
Then by all means give us a call.
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
More information about the seaside