[Pharo-project] #& in Socket >> #waitForSendDoneFor:

Philippe Marschall kustos at gmx.net
Tue Nov 9 20:21:45 CET 2010

On 09.11.2010 07:58, Schwab,Wilhelm K wrote:
> What does your patch do?

It replaces the #& with and #and: swaps receiver and argument to
preserve the same semantics. That saves a primitive call if the data is
already sent. It's basically the same as posted by Levente.

> At a minimum, it deserves a little attention.  Things that come to mind are that one version does less work due to some type of optimization (and runs faster as a result) or that one is too quick to detect a loss of connection and sends less data per opportunity, appearing to run slower as a result.
> Can you elaborate on "I'm able to push about 1 Mbyte/s more"?  I guess I'm asking how that manifests itself?  Are there a bunch of connections that form, send and fail?  Do they each get a little farther or do they go faster?

Throughput outgoing from the Pharo image was about 1 Mbyte/s higher. Now
I can't reproduce it anymore so it was probably a measuring inaccuracy.
That was making 100000 HTTP requests with Apache bench, keep alive and a
concurrency level of 10.

Apache (the server, not the bench) opens 10 persistent worker
connections to the Pharo image each having it's own process an socket so
the load should be pretty well spread across them. Then it's Seaside and
writing a constant 16 Kbyte byte array to the response without encoding
or rendering.

It's exactly the same incoming and outgoing traffic, it just finished

> Also, my standard objection to timeouts enters into this.

It's on localhost, the longest request takes about 20ms to finish and
#sendSomeData:startIndex:count: has a timeout of 20sec. Sending the
entire response is four sends to #sendData:count: which is at least four
#waitForSendDoneFor: sends.

> IMHO, the socket should do what it is asked to do, blocking only the calling thread, and let other threads and/or the user decide when that is taking too long.

What does this have to do with replacing a #& with a #and:?

> Could you be getting timeouts that are causing unexpected behavior?

I don't think so, see above. Since I can't reproduce it anymore it was
probably a measuring inaccuracy (~3 %). However I think it's still
worthwhile replacing that #&.


More information about the Pharo-project mailing list