[Seaside] Are Collections threadsafe?
stephane.ducasse at free.fr
Wed Feb 27 14:58:28 UTC 2008
why don't you sell VMs and VM improvements?
This would be great and you would get money and we would get more
May be this is naive but I would pay on a regular basis for a squeak
vm for our team.
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
>> a problem with a db connection pool that was protected by a
>> Whether it worked or not depended on the priority of the thread
>> accessing it. But of course implying there is something wrong with
>> VM or Image is considered heresy. If you have such issues, better
>> fix them yourself. This is easy because "the source it there" (tm).
>> 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 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://
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside