[Seaside] Are Collections threadsafe?

stephane ducasse stephane.ducasse at free.fr
Wed Feb 27 14:58:28 UTC 2008


Hi john

why don't you sell VMs and VM improvements?
This would be great and you would get money and we would get more  
stable system?
May be this is naive but I would pay on a regular basis for a squeak  
vm for our team.

Stef



On Feb 26, 2008, at 11:49 PM, John M McIntosh wrote:

>
> 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
> = 
> = 
> = 
> = 
> = 
> ======================================================================
>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>


More information about the seaside mailing list