experienced opinions
in [Unix Programming]
|
From: Bill Cunningham on 29 Apr 2010 20:27 I would like to know from those out there which they have used most easily for internet sockets; select() or poll() ? From what I've been reading from this page http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html#poll I am leaning more towards poll(). I have finally completed my first server side socket excepting for recv() and a multiplexing function; such as poll(). Thanks for any opinions or ideas. Bill
From: Bill Cunningham on 29 Apr 2010 21:23 "Bill Cunningham" <nospam(a)nspam.invalid> wrote in message news:4bda23dd$0$12419$bbae4d71(a)news.suddenlink.net... > I would like to know from those out there which they have used most > easily for internet sockets; select() or poll() ? From what I've been > reading from this page > > http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html#pollman Oops that the right part of the page. Here's what I have here with error checking out for brevity and no recv() or send(). It compiles and that was my main concern. Now after recv() is added I need poll() or select(). #include <string.h> #include <netdb.h> #include <netinet/in.h> #include <sys/socket.h> #include <sys/types.h> struct sockaddr_storage theirs; struct addrinfo ad, *p; int sock, nsock; socklen_t stheir; int main() { memset(&theirs, 0, sizeof theirs); memset(&ad, 0, sizeof ad); ad.ai_family = PF_INET; ad.ai_socktype = SOCK_STREAM; ad.ai_flags = AI_PASSIVE; getaddrinfo(NULL, "21", &ad, &p); sock = socket(p->ai_family, p->ai_socktype, 0); bind(sock, p->ai_addr, p->ai_addrlen); listen(sock, 5); stheir = sizeof theirs; nsock = accept(sock, (struct sockaddr *) &theirs, &stheir); return 0; } Bill
From: David Schwartz on 29 Apr 2010 21:56 On Apr 29, 5:27 pm, "Bill Cunningham" <nos...(a)nspam.invalid> wrote: > I would like to know from those out there which they have used most > easily for internet sockets; select() or poll() ? From what I've been > reading from this page > > http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html#poll > > I am leaning more towards poll(). I have finally completed my first server > side socket excepting for recv() and a multiplexing function; such as > poll(). Thanks for any opinions or ideas. I recommend using 'poll' for two reasons. First, it distinguishes between a closed/error connection and a ready connection immediately, whereas 'select' makes you call a reading or writing function to tell. This simplifies the fast paths for connection shutdown. (But you still have to handle a close/error from 'read' or 'write' since the error or close may occur later.) Second, it doesn't become inefficient when the descriptor index is large. Due to the way the 'select' sets are composed, 'select'ing on higher-numbered descriptors is less efficient and can get you into trouble depending on how the C library was compiled. DS
From: Rainer Weikusat on 30 Apr 2010 08:29 "Bill Cunningham" <nospam(a)nspam.invalid> writes: > I would like to know from those out there which they have used most > easily for internet sockets; select() or poll() ? From what I've been > reading from this page > > http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html#poll > > I am leaning more towards poll(). I have finally completed my first server > side socket excepting for recv() and a multiplexing function; such as > poll(). I always use poll because I consider the interface to be saner. - Passing a bitmap of interesting file descriptors was a 'clever hack' by the time select was invented --- due to limitations in the Berkeley UNIX(*) kernels of this time, any theoretically possible descriptor set would fit into a 32bit word (the maximum number of open files for a process was <32). Nowadays, it is an idiotic[*] idea (cf David's remark regarding descriptor numbers) - When using poll, the data structures defining the interest set are under application control because the kernel uses a special structure member to communicate event information. For select, the kernel destroys the interest set because the same memory area must be used to provide 'result information' to userspace. This implies that the interest set bitmasks must be recreated for each select-call which is cumbersome and wasteful - an current fd set is much larger that a few pollfd structures, potentially[**] causing a lof of uninteresting bytes to be copied into and out of the kernel [*] Originally, 'idiot' was used to describe a person incapable of learning anything because of the unshakeable to conviction to already know everything. [**] It is possible to 'optimize' this copy process for suitable (non-sparse) descriptor sets. The computer then needs to load a lot of code from memory instead of a lot of data ...
From: boltar2003 on 30 Apr 2010 08:41
On Fri, 30 Apr 2010 14:29:44 +0200 Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote: >I always use poll because I consider the interface to be saner. > > - Passing a bitmap of interesting file descriptors was a > 'clever hack' by the time select was invented --- due to > limitations in the Berkeley UNIX(*) kernels of this time, > any theoretically possible descriptor set would fit into a > 32bit word (the maximum number of open files for a process > was <32). Nowadays, it is an idiotic[*] idea (cf David's > remark regarding descriptor numbers) OTOH with poll you have to manually maintain the array of pollfd structures you're passing in. With select you can let the FD_ macros do all the work for you. Unless you hard code the array size then any efficiency gains you get through using poll() you'll soon lose by having to use a vector<> or realloc() Also poll doesn't return the amount of time left if in timeout mode and something happens unlike select. B2003 |