Squeak Socket Primitives

Bijan Parsia bparsia at email.unc.edu
Wed Nov 10 03:56:09 UTC 1999


At 10:02 PM -0500 11/9/99, Mark Guzdial wrote:

[snip]
>I did read through the page, Craig -- thanks for doing it.

So did I. It is nice. If I can get a 2.6 with and without correspondents up
tomorrow, I'll see if I can generate some benchmarks. And more cogent
remarks, but I wanted to respond to Mark's point here (as I did on the
Squeaker's list) just so both sides are represented :)

[snip]

>But one of the arguments that I disagree with was the issue of whether to
>use Slang or handwritten C for the primitives.

The issue is actually, if I understand Craig correctly, whether to use a
mix of Slang and handwritten C, or *just* handwritten C, for these
primatives. I suspect that there's a "natural" breaking point where it
doesn't make sense to Slang if you have to C. I'd be interested in hearing
from Slangers about this.

>  The design philosophy of
>Squeak is one I strongly agree with: Everything in Smalltalk, as much as
>possible.  Performance is always being improved, but the goal of having the
>system understandable from a single image, and as much as possible, from a
>single language has always been paramount.

I've argued that the real philosophy is (in part) Consistency, Simplicity,
and Transparency. Typically, that means putting it all in Squeak. But take
something like the Regex plugin. The Regex plugin (again, if I understand
it correctly) makes a C library callable from Squeak. It makes sense to
have that library look like a good C library, rather than, say, trying to
cut and paste individual routines glued by Slang in some mishmash. *That*
just makes things more confusing. Of course, that might be a good
*intermediate step* toward porting the library to Slang/Squeak, but a true
and useful port is going to have to do more than *that*.

And this is basically Craig's argument:

>>understand. I don't see much benefit in having part of the primitive
>>source in Smalltalk when most of it is in handwritten C, at least until
>>someone writes the IP stack itself in Smalltalk (I almost did this for
>>Interval...).

Using handwritten C is (supposed to be) a kind of stop gap measure. *Some*
hand C has to get in, so it might as well be the *cleanest* hand C we can
get.

>From my perspective, I'd prefer a slower implementation that remained
>explorable from Squeak

Speaking as a non-C person who has spent a *lot* of time inside the Squeak
socket code, I *don't* think the current implementation is all that
explorable.

> to one that has details down in C code that I lack
>the tools and expertise to explore.

It's true with the current example as well (which is what stymied my
investigations of the "rouge UI slow down" between 2.2-2.6--I waste a fair
bit of time before I realized that it was hopeless without looking at the C
code, I think!).

So I agree that having everything is Squeak *is* the ideal, and to be
striven for. The question is what to do when that's not possible. Making
the boundary as *clear* as possible, and making the "out of Squeak" stuff
as simple as possible, strikes me as the right idea (espeically so that one
doesn't waste time :))

>That's just one Squeaker's opinion.

And another's! :)

I'm glad the socket/networking issue is getting hashed out!

The greasy Squeaker makes the wheel go round....or something :)

Cheers,
Bijan.





More information about the Squeak-dev mailing list