Re: [OT] Two sockets questions

["Tarjei T. Jensen" <tarjei@online.no>]

"Tarjei T. Jensen" <tarjei.jensen@akerkvaerner.com> wrote in message
news:3ebcbefb$1@news.wineasy.se...
>
> "Jano"  wrote
> > I'm a bit afraid of using so many (say two thousands) tasks (are they
> > really that light? What computer is necessary for that number? I have a
> > pretty decent one, but...) but really I haven't past experiences about
> > so many threads. However, as I've never seen an application so task
> > intensive, I've think that that is for some reason (my httpd apache uses
> > 253 and is the most I've seen).

New answer (google is my friend)

The Winsock programmers FAQ http://tangentsoft.net/wskfaq/ says
2.8 - Winsock keeps returning the error WSAEWOULDBLOCK. What's wrong with my
program?
Not a thing. WSAEWOULDBLOCK is a perfectly normal occurrence in programs
using non-blocking and asynchronous sockets. It's Winsock's way of telling
your program "I can't do that right now, because I would have to block to do
so."

The next question is, how do you know when it's safe to try again? In the
case of asynchronous sockets, Winsock will send you an FD_WRITE message
after a failed send() call when it is safe to write; it will send you an
FD_READ message after a recv() call when more data arrives on that socket.
Similarly, in a non-blocking sockets program that uses select(), the
writefds will be set when it's okay to write, and the readfds will be set if
there is data to read.

Note that Win9x has a bug where select() can fail to block on a nonblocking
socket. It will signal one of the sockets, which will cause your program to
call recv() or send() or similar. That function will return WSAEWOULDBLOCK,
which can be quite a surprise. So, a program using select() under Win9x has
to be able to deal with this error at any time.

This gets to a larger issue: whenever you use some form of nonblocking
sockets, you have to be prepared for WSAEWOULDBLOCK at any time. It's simply
a matter of defensive programming, just like checking for null pointers.



Quote from the Unix socket FAQ (http://www.developerweb.net/sock-faq/):
9. What are the pros/cons of select(), non-blocking I/O and SIGIO?

Using non-blocking I/O means that you have to poll sockets to see if there
is data to be read from them. Polling should usually be avoided since it
uses more CPU time than other techniques.

Using SIGIO allows your application to do what it does and have the
operating system tell it (with a signal) that there is data waiting for it
on a socket. The only drawback to this soltion is that it can be confusing,
and if you are dealing with multiple sockets you will have to do a select()
anyway to find out which one(s) is ready to be read.

Using select() is great if your application has to accept data from more
than one socket at a time since it will block until any one of a number of
sockets is ready with data. One other advantage to select() is that you can
set a time-out value after which control will be returned to you whether any
of the sockets have data for you or not.


-- End of Quote --

Related Web sites:

Winsock tuning FAQ http://www.cerberus-sys.com/~belleisl/mtu_mss_rwin.html

Raw IP Networking FAQ http://www.whitefang.com/rin/

Unix programming FAQ http://www.erlenstar.demon.co.uk/unix/

The TCP/IP FAQ http://www.itprc.com/tcpipfaq/default.htm