delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1997/10/02/13:27:58

From: newsham AT aloha DOT net (Tim Newsham)
Subject: Re: Problems with Sockets and select.
2 Oct 1997 13:27:58 -0700 :
Message-ID: <199710022003.KAA12258.cygnus.gnu-win32@haleakala.aloha.net>
References: <9710020556 DOT ZM26097 AT xvn DOT ds DOT boeing DOT com>
Mime-Version: 1.0
To: blair AT xvn DOT ds DOT boeing DOT com (Rick Blair)
Cc: gnu-win32 AT cygnus DOT com

> Hi all,
> 
> This is a follow up to another post I made {with no replies :-( }
> 
> I have an application that does interprocess communication with sockets.
> The main server process does a select to multiplex I/O from the clients.  The
> select call completes, but when I go to read the socket with input pending,
> I block on the read call.  Which is strange, since select says there is input
> ready for that socket.
> 
> This same code works in almost all flavors of Unix that I have tried.
> 
> Any suggestions or work arounds would be helpfull.

In winsock, a read/recv() will block until the full amount
of data requested is available if you aren't in non-blocking
mode.  So if you do read(s, buf, 2), and there is only 1 byte
available, you will block until there are 2.  This is not the
same behavior observed in unix.  You can do an ioctl to determine
the number of bytes actually available after the select (FIONREAD)
and read only that amount, to avoid blocking.

> Rick
> * email:   blair AT xvn DOT ds DOT boeing DOT com  * The contents of this message in    *
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019