Problems with sockets with 3.6 Carbon VM?

John M McIntosh johnmci at smalltalkconsulting.com
Wed Oct 8 07:08:57 UTC 2003


Right, when I look at
http://cvs.sourceforge.net/viewcvs.py/squeak/squeak/platforms/unix/ 
plugins/SocketPlugin/sqUnixSocket.c
I see Tue Sep 16 07:56:51 2003 UTC (3 weeks ago) by piumarta
now of course he could be running more 'Alpha' code via his site.

Lets see first I couldn't get the

>> machine := #(127 0 0 1).
>> 	port := 5132.
>> 	socket := Socket newTCP.
>> 	socket connectTo: machine port: port.
>> 	socket semaphore wait.

to run, that creates an array for machine, but the primitive wants a  
bytearray and it invokes a primitive failed.
So I changed it to
machine _ NetNameResolver localHostAddress.
which in my opinion is better than hard coding a magic number in any  
case.

I also had to change your connection logic to
	serverSocket _ Socket newTCP.
	serverSocket listenOn: 53811 backlogSize: 4.
	serverSocket semaphore wait.
	serverSocket isConnected
			ifTrue: [peerSocket := serverSocket accept.
					peerSocket inspect]


Now what I found was that the semaphore get signalled, then we invoke  
the isConnected call
isConnected
	"Return true if this socket is connected."

	socketHandle == nil ifTrue: [^ false].
	^ (self primSocketConnectionStatus: socketHandle) == Connected

which asks for the connection status, then it does the follow C code.  
You'll note that the Server Socket State is Connected, however
it's NOT readable, thus the socket state goes to OtherEndClosed.
This returned results fails the if block because it's not equal to  
Connected.

I can't comment on what the real logic should be. MMM I do note this  
*was* the change that Ian made on the 16th to the source.
I'll invite more comment? Perhaps a linux user can try with a swiki and  
see what happens?


int sqSocketConnectionStatus(SocketPtr s)
{
   if (!socketValid(s))
     return Invalid;
   /* we now know that the net session is valid, so if state is  
Invalid... */
   if (SOCKETSTATE(s) == Invalid)	/* see acceptHandler() */
     {
       fprintf(stderr, "socketStatus: freeing invalidated pss=%p\n",  
PSP(s));
       /*free(PSP(s));*/	/* this almost never happens -- safer not to  
free()?? */
       _PSP(s)= 0;
       interpreterProxy->success(false);
       return Invalid;
     }
   /* check for connection closed by peer */
   if (SOCKETSTATE(s) == Connected)
     {
       int fd= SOCKET(s);
       int n=  socketReadable(fd);
       if (n < 0)
	{
	  FPRINTF((stderr, "socketStatus(%d): detected other end closed\n",  
fd));
	  SOCKETSTATE(s)= OtherEndClosed;
	}
     }
   FPRINTF((stderr, "socketStatus(%d) -> %d\n", SOCKET(s),  
SOCKETSTATE(s)));
   return SOCKETSTATE(s);
}

The sqMacNetwork.c code which is the 'OLD' OpenTransport solution for  
os-7.5.3-os-9.x & a shim on top of BSD sockets in OS-X is completely  
different and never sets the server socket to Other End Closed unless a  
close request comes in for that socket. Which would never happen.

On Tuesday, October 7, 2003, at 06:30  PM, Phil Hargett wrote:

> Per an earlier note to the list from Ian Pumarta, I checked to see  
> what I have for sqUnixSocket.c, and I find that I have the same  
> version that I had a few weeks ago:
>
> -rw-r--r--  1 phil  staff  37721 Sep 16 03:56 sqUnixSocket.c
>
> I believe Ian was looking for a September 30th version of this file.    
> Also, aio.c reports as:
>
> -rw-r--r--  1 phil  staff   8091 Oct  6 20:11 aio.c
>
> Finally, I checked out Ian's Unix distribution (3.6g2), and I found:
>
> -rw-r--r--  1 phil  staff  37734 Sep 16 14:06 sqUnixSocket.c
>
> and
>
> -rw-r--r--  1 phil  staff  8075 Aug 30 07:04 aio.c
>
> So, don't know which version to use.
>
> I might try aio.c from Ian's distro, to see if that cleans things up.
>
>
> On Tuesday, October 7, 2003, at 08:19  PM, Phil Hargett wrote:
>
>> Okay, so a few weeks ago I brought up a potential issue with Sockets  
>> on the Mac OS X Carbon VM, and, unfortunately, I couldn't rule out my  
>> own errors from being the cause.
>>
>> I've now rebuilt the VM from CVS, just after John McIntosh's  
>> announcement of a new VM.  What I've found is that using 2 different  
>> SocketPlugin's have different effects, causing the same Smalltalk  
>> code to behave differently.  In one case, the code appears to do it's  
>> job; in the other, it does not.
>>
>> Using the Project Builder project found in CVS, the Mac OS Carbon VM  
>> uses sqUnixSocket.c for the SocketPlugin; the file sqMacNetwork.c is  
>> not included in the build.  After building the VM with the defaults  
>> (and following the instructions found in CVS), I then ran the  
>> following snippet of code to open a socket:
>>
>> 	machine := #(127 0 0 1).
>> 	port := 5132.
>> 	socket := Socket newTCP.
>> 	socket connectTo: machine port: port.
>> 	socket semaphore wait.
>>
>> On the receiving end (in the same VM, just another process):
>>
>> 	serverSocket semaphore wait.
>> 		serverSocket isConnected
>> 			ifTrue: [peerSocket := serverSocket accept.
>> 					peerSocket isConnected: ["Do stuff with this new connection"].
>>
>> What I've discovered is that in the VM built with sqUnixSocket.c  
>> (built by default), is that although the waiting receiver does return  
>> from the Socket>>semaphoreWait call, it never receives a connected  
>> socket, so it just spins endlessly on the Socket>>semaphoreWait call.
>>
>> When I build with sqMacNetwork.c instead (*not* the default), a  
>> connected socket is returned from the Socket>>accept call, and my  
>> code continues processing the connection.
>>
>> So...am I writing my Smalltalk code incorrect?  Or is there something  
>> wrong with the Project Builder project, that it should be using  
>> sqMacNetwork.c instead of sqUnixSocket.c when building the Carbon VM?  
>>  Or is there something up with sqUnixSocket.c?  Something  
>> else...perhaps a problem with semaphore handling?
>>
>> Don't know, although I've eliminated problems with my build process  
>> (followed instructions), source code used for the build (pulled from  
>> CVS this week), and tested my code in a working VM to ensure it's not  
>> just a fluke.
>>
>> Any insight?
>>
>>
>
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===



More information about the Squeak-dev mailing list