From: lcargill99@comcast.com   
      
   Rick Jones wrote:   
   >> Sadly, requests can span multiple calls to recv(), but I can call   
   >> read() and store any read characters to be consumed when the recv()   
   >> call occurs. Basically, all read data is buffered, then parsed when   
   >> a complete request arrives.   
   >   
   > When I was saying "read return of zero" I was using read in the   
   > general sense.  Any of the "read" calls - read(), recv(), recvfrom(),   
   > recvmsg() ... should return zero when the FIN has arrived from the   
   > remote.   
   >   
   > rick jones   
   >   
      
      
   understood. Sorry I was so slow on the uptake. "But I've already read   
   it!" :) FWIW, I *did* add read() calls before send() and have left them   
   there in case any other such unhandled nasties lurk. I've   
   basically wrapped send(), which was a good idea anyway - there's   
   only the single point that way.   
      
   As it turns out, Barry Margolin exactly recognized my problem and   
   that's now also fixed - a SIGPIPE was the culprit.   
      
   That will cause send() to return an error code which is   
   subsequently handled. this was 100% reproducible before;   
   now it's gone.   
      
   Maybe I'll get to porting/building strace but there was a small   
   landslide of higher priorities today.   
      
   Thanks all very much. It's great when Usenet works as well   
   as this. I owe beers or equivalent.   
      
   --   
   Les Cargill   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)