[Pharo-project] Pharo suffers internal Traffic Jams ...

Schwab,Wilhelm K bschwab at anest.ufl.edu
Sun Nov 6 11:54:14 EST 2011


Interesting.  On the subject of traffic, that simulation is not realistic :)  First, you need the college kid in a $50k sport car (complete with lights underneath it, noise-enhancing exhaust and custom rims) talking on a cell phone instead of driving.  You also need to add an old lady with her turn signal blinking for miles.

Looking at other links, this one caught my eye:


I was caught in a jam like they describe, but on a small scale.  There is one thing they forgot to mention: people sitting a standstill at the front of the line of traffic and paying NO attention to when they might be able to make forward progress.  You had to see this one to believe it - trust me.

Back to software, EXCELLENT point about slow machines revealing defects.  50MHz might be overkill, but the point is well taken.  This (and some of its links) might be of interest:


My guess is that the system itself should do very little based on time itself; things should happen based on events.  Decisions about what is fast/slow or critical/nonnegotiable are probably best made at the application level.


From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Guido Stepken [gstepken at googlemail.com]
Sent: Sunday, November 06, 2011 9:05 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: [Pharo-project] Pharo suffers internal Traffic Jams ...

Hi guys!

Please first first have a look at that simulation:


Surprisingly the architecture of pharo looks very much this. Message sends, "information flow" through a dynamic ambience of "living objects" cause serious "hangs"

Unpredictable traffic jams occurr, depending on load, e.g. Seaside, during GC, Image sync, subtile timeouts or countdows, waiting for resources to be freed, network timeouts, database lookups, e.t.c.

Those can much easier be identified, when you downclock your machine to good old 50MHz of ancient times of squeak and develop/profile then. Design flows pretty soon become visible then, that are not visible when you proudly use always the newest Apple machine for development.

>From advanced Software architects of a new old Smalltalk OS i expect to know about such dynamic phenomenons, having deep insight into analytically identifying such normally difficult to indentifying problems, that always should be part of TDD ...

Tnx for reading and understanding.

Have fun!

Guido Stepken

More information about the Pharo-dev mailing list