Amos Shapira wrote: > > in neither case will read return 0. the only time that read is allowed > to return 0, is when it encounters an EOF. for a socket, this happens > ONLY if the other side closed the sending-side of the connection. > > > Is there an on-line reference (or a manual page) to support this? man 2 read > From what I remember about select, the definition of it returning a > "ready to read" bit set is "the next read won't block", which will be > true for non-blocking sockets any time and therefore they weren't > encouraged together with select. I believe you two are talking about two different things here. There is a world of difference between UDP and TCP in that regard.
UDP is connectionless. This means that read's error codes relate only to the latest packet received. UDP also doesn't have a 100% clear concept of what "CRC"/"checksum" actually means. I still think it's a bug for "select" to report activity on a socket that merely received a packet with bad checksum (there is no CRC in TCP/IP), as how do you even know it was intended for this socket? In TCP, on the other hand, a read is related to the connection. Packets in TCP are coincidental. Under TCP, read returning 0 mean just one thing - the connection is close. > > if you have so many connections that multiple threads will become a > problem then a single thread having to cycle through all these > connections one by one will also slow things down. No, my experience begs to differ here. When I tested netchat (http://sourceforge.net/projects/nch), I found out that a single thread had no problem saturating the machine's capacity for network in/out communication. As long that your per-socket handling does not require too much processing to slow you down, merely cycling through the sockets will not be the problem if you are careful enough. With netchat, I used libevent for that (see further on for details), so I was using epoll. Your mileage may vary with the other technologies. > Not to mention the signal problem and just generally the fact that one > connection taking too much time to handle will slow the handling of > other connections. Yes, it is probably better to use a single thread that does the event waiting, and a thread pool for the actual processing. Having one thread pet socket, however, is not a wise idea IMHO. > A possible go-between might be to select/poll on multiple FD's then > handing the work to threads from a thread pool, but such a job would > be justifiable only for a large number of connections, IMHO. It's not that difficult to pull off, and I believe your analysis failed to account for the overhead of creating new threads for each new connection, as well as destroying the threads for no longer needed connections. > If you insist on using a single thread then select seems to be the > underdog today - poll is just as portable (AFAIKT), and Boost ASIO > (and I'd expect ACE) allows making portable code which uses the > superior API's such as epoll/kqueue/"dev/poll". Personally, I use libevent (http://www.monkey.org/~provos/libevent/), which has the advantage of being a C linkage program (ASIO is C++, as is ACE). It also has a standard license (three clause BSD). I skimmed over the boost license, and it doesn't seem problematic, but I don't like people creating new licenses with no clear justification. Shachar ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
