[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.
>
> Cheers
> Philippe


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  
toss it...

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 mailing list