Problem with Socket under Linux...

Göran Hultgren gohu at
Tue Apr 23 08:29:47 UTC 2002

Hi John!

First of all - I just verified (using the somewhat clumsy test procedure I posted earlier) that it
works fine under Win32 - both the processes wait nice and quietly on their semaphores - no CPU

As a sidenote: I also note that when running the test the UI process takes 20% and the idle
process about 80% instead of the UI process sucking all there is left (as it seems to do on my
Linux box).

--- John M McIntosh <johnmci at> wrote:
> >  > I don't really know why this code looks like it does but I do wonder why
> >>  the unix version notifies the readSemaphore even if the socket is not
> >>  "socketReadable".
> >
> >It probably comes from my misunderstanding of exactly the conditions
> >under which the semaphore should be signalled.  (As far as I know,
> >nobody ever specified the behaviour of the socket semaphore stuff in
> >any kind of rigorous manner -- so I'm basically guessing where to
> >signal them.)  If the Unix and win behaviours differ then I happily
> >concede that the win version is probably right.
> Na.... it comes from the Mac VM.
> See for an long 
> detailed explanation of the semaphore states.

Ok, I read it briefly but some of it flew over my head. Good stuff though.

Let me ask you a few questions, you write (on the page mentioned):
> In my implementation we only arm the semaphore after seeing the primSocketReceiveDataAvailable
> responding there is no data. We know that the next thing that will happen (baring the deadline
> timeout) is that the process will be waiting on the semaphore.

"arm the semaphore"? "Tap"? I haven't worked that much with semaphores. You mean that it must be
"armed" in order to be "fired" (signalled) later when data does arrive? And is that called
"tapping" the semaphore? Excuse me for my silly questions...

Then... you do not in fact signal the semaphore when there is no data - right? (I don't really
know what your last line before "return 0" does, is that the "arming" stuff? Hey, btw, the Unix
version returns -1 if the socket is not valid, not 0...)

The thing I don't understand with the Unix version is why we signal the readSemaphore (well, it's
not an immediate signal, it's a pending event - the semaphore will be signaled on the next call to
notify() - how/when that call is done I don't know but since the semaphore does indeed get
signalled AFAICT it must have been called somehow...).

I mean... why? :-) Ian proposed I should just skip that line, which I will try out, but I would
really like to know why it's there from the beginning...

Mac version included:
>//Check to see if bytes are available
>int sqSocketReceiveDataAvailable(SocketPtr s)
>    EPInfo* epi;
>    static lastTickCount=0;
>        if (!SocketValid(s)) return 0;
>    epi = (EPInfo *) s->privateSocketPtr;
>    if (epi->bytesPendingToRead > 0)
>        return 1;
>    if (OTAtomicTestBit(&epi->stateFlags2, kReadFlowControl)) // New case if dat
>a pending but flow controlled then go get it
>        return 1;
>    OTAtomicSetBit(&epi->stateFlags2, kTapSemaphoreReadData); //Note how we impl
>y there will be interest in semaphore
>    return 0;

> For an Sunit test suite try
> The ability to run the test suite (which requires changes for host 
> names) shows the VM implementation of sockets is (I'd guess) 
> compatible with the mac version.

Yeah, when I come to think of it I actually knew you had all this stuff but had forgotten, this
need to be put on the Swiki! If I change anything I will sure test with it.

> Failure to run the test suite, means you can write code on the mac 
> which works, but fails on your platform. Is that a good thing? I 
> can't answer that question.

Hehe. Well, since your suite is the only one we got I would say that if it fails something should
be fixed, either the suite or the platform support code that fails.

regards, Göran

Göran Hultgren, goran.hultgren at
GSM: +46 70 3933950,
"Department of Redundancy department." -- ThinkGeek

Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more

More information about the Squeak-dev mailing list