[Pharo-project] Networking change in Pharo 1.2?

Henrik Sperre Johansen henrik.s.johansen at veloxit.no
Wed Apr 20 01:13:02 CEST 2011

On 19.04.2011 20:19, Eliot Miranda wrote:
> Hi Henrik,
> On Mon, Apr 18, 2011 at 1:23 AM, Henrik Sperre Johansen 
> <henrik.s.johansen at veloxit.no <mailto:henrik.s.johansen at veloxit.no>> 
> wrote:
>     On 17.04.2011 22:48, Chris Muller wrote:
>         I was able to work on getting Magma 1.2 going in Pharo.  It
>         was quite
>         easy to get the code loaded and functioning in Pharo 1.1.1,
>         Pharo 1.2,
>         and Pharo 1.3.
>         But something seems to have changed in Pharo's networking from
>         1.1.1
>         to 1.2.  All Magma functionality seems to work fine for low-volume
>         activity.  However, when the test-suite gets to the HA test
>         cases (at
>         the end), one of the images performing heavy networking activity,
>         consistently gets very slow and bogged down for some reason;
>         causing
>         the clients to timeout and disrupting the test suite.
>          Fortunately, it
>         happens in the same place in the test-suite every time.
>         The UI of the image in question becomes VERY sluggish, but
>         MessageTally spyAllOn: didn't reveal anything useful.  What is it
>         doing?  I did verify that the Magma server in that image is still
>         functioning; clients were committing, but I had to increase their
>         timeouts from 10 to 45 seconds to avoid timeouts..
>         Unfortunately, two days of wrangling in Pharo (because I'm an old
>         Squeak dog) I could not nail the problem down; but I have one
>         suspect..  A couple of times, I caught a process seemingly
>         hung up in
>         NetworkNameResolver; trying to resolve an IP from 'localhost'.
>         This exact set of Magma packages is rock-solid on Pharo 1.1.1 and
>         Squeak, but that doesn't mean the problem for sure lies in
>         Pharo 1.2;
>         maybe a networking bug in 1.1.1 is allowing Magma to "misuse" the
>         network and get away with it and Pharo 1.2 is now more strict?  I
>         don't know, I would just like to ask the experts here for help who
>         know all what went into Pharo 1.2 so hopefully we can get to the
>         bottom of it.
>         Thanks,
>           Chris
>     Which VM did you run these tests on?
>     IIRC, Cog has a hard limit on how many external semaphores are
>     available, and each Socket consumes 3 of those.
> Not so.  The limit is soft.  It can be accessed using Smalltalk 
> vmParameterAt: 49.  It defaults to 256 entries.  It maxes out it 64k 
> entries because the value set via vmParameterAt: 49 put: X persists in 
> a short in the image header.  I expect 20k sockets to be sufficient 
> for a while, right?
Ah, absolutely :D

That's what I get for skimming readme's,  think it'd be good to upgrade 
the comment though?
No specific mention is made that it can be(although frowned upon)/how to 
set it after startup, currently it reads:
"Another significant change is in the external semaphore table support 
This is now lock-free at the cost of having to specify a maximum number of
external semaphores at start-up (default 256)."

I guess having it accessible from image is one interpretation of that 
line, personally I thought it was that you could use some parameter when 
launching the executable :)

Also, it's currently possible to register more than this limit in 
current images (Smalltalk registerExternalObject:) without an error.
Am I correct in my reading of the code that when this happens, they will 
never be signaled?
If so, we'd probably want to do some changes to ExternalSemaphoreTable :)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110420/49a2161b/attachment.htm>

More information about the Pharo-project mailing list