Socket not connected exception

Hi,
in my source code there's a method where I'm fiddling with  
UnixProcess>>cshOne:

I'm using it to launch a command-line script which processes some  
data to generate a png file, like this:

UnixProcess cshOne: 'cd ~/Desktop/ ; /usr/local/bin/generatePNG ',  
inputFile, ' ; open outputFile.png'.

Everything works fine, but after a number of tries I get am unhandled  
exception "Socket is not connected".

Does anybody have a clue where the problem may be?

Thanks,

Michele

Michele Lanza wrote:
I have seen this error regularly and I used to think that it had to do
with the allocation rate of (OS level) sockets and VW possibly not
releasing them early enough (but later when it does a GC).

I never looked into the issue properly but got into the habit of
'fixing' it by allocating less of these sockets. In your case that would
probably mean starting a bash shell from VW and keeping it around while
you push your image processing commands into that bash instance one at a
time.


I did do some light testing to see if forcing a GC would help -- it
didn't. (See also pkg ForceFinalization in the Open Repository).


Moreover this facility seems capable of bringing the OS to its knees!!!

Running the following snippet seems to reliably hang my
MacMini/Intel/OSX10.4.11 after about 10 minutes.

[   | count |
    [   count := 0.
        [   UnixProcess cshOne: 'echo foo'.
            count := count + 1
        ] repeat
    ] on: Error do: [ :ex | Transcript space; print: count]
] repeat


I don't know whether my Mac goes into livelock or deadlock -- not quite
sure how to find that out...



R
-

Reinout Heeck wrote: Using your sample script and netstat it is easy to see that VW is
allocating a TCP socket for each cshOne: call.  When the "remote" (shell
command) end of the socket is closed the socket itself has to sit in a
TIME_WAIT state for a while.  This is normal behavior for a TCP socket
and GC-ing won't help.  The question remains: why does VW use a socket
to implement "pipe" behavior?  It looks like UnixPipeAccessor>>openPair
doesn't actually use a UNIX pipe at all but instead two sockets.  I'm
sure the Cincom engineers can explain why but frankly it is a cruddy
implementation of a "pipe" whatever the reason.  If, for some reason,
actual UNIX pipes don't suit the purpose then VW could use a UNIX domain
socket rather than a TCP socket.

David