experienced opinions
in [Unix Programming]
|
From: David Schwartz on 5 May 2010 06:49 On May 4, 4:26 am, boltar2...(a)boltar.world wrote: > If they don't understand bitmaps then they haven't learnt C properly and > so they're unlikely to understand memory management properly either. Well, part of the problem is that they don't necessarily even know that they're bitmaps. You'll seldom see that mentioned in the documentation for 'select' and nothing in any standard (as far as I know) requires them to be bitmaps. The fact is, there's a set of classic errors people make in 'select' that we see all the time. Failing to reinitialize the fd sets is a mistake almost everyone seems to make the first time they use 'select'. There really are no such errors with 'poll'. I don't think this is because 'poll' is simpler, I think it's largely because people cut their teeth on 'select' and don't even try to mess with 'poll', typically, until they're more experienced. In fact, the only common error I see with select is thinking that 'poll' will return writability or readability if the connection closes or errors. And the only people expect this behavior, typically, is because it's what 'select' does. (Had they started out with 'poll', they likely wouldn't have expected this.) Frankly, I don't think easier is simpler or more complicated than the other. They both have their little quirks that bite people (like maxfd +1 in 'select' and that you have to test for events you didn't ask for in 'poll') and they both have their deep pits of confusion (like POLLPRI versus POLLRDBAND for 'poll' and like what's an 'exception' for 'select'). For a typical program handling a small number of connections with no significant performance requirements, they behave identically. DS
From: Rainer Weikusat on 5 May 2010 07:29 "Ersek, Laszlo" <lacos(a)caesar.elte.hu> writes: [...] > I like to understand function specifications in depth before calling > said functions. No matter how superior you prove poll() if I'm not > sure I can call it correctly. When I say "I'd stick to select() > [unless you prove poll() un-messy -- please do!]", isn't that > invitation for you to prove poll() un-messy? As I already wrote: You are (correctly) seeing all kinds of theoretical problems which practictally don't exist. I can give you an entirely practical viewpoint in the hope that it will communicate something sensible. I cannot go and change Linux manpages (except on my own system) or even the UNIX(*) standard text. I care for exactly two things wrt 'I/O multiplexing', namely 'can I read data' and 'can I write pending data'. I have so far not found any uses for 'TCP urgent data'[*]. I don't care for STREAMS. They are not supported on Linux and hence, irrelevant for new code[**]. This implies that I use POLLIN and POLLOUT (when appropriate) for events and usually map anything 'weird' which might be returned in revents to POLLIN. If it is an EOF, read will detect that. The same is true for any kind of error condition. I have so far not had any problems which could have been solved by ppoll (which exists on Linux, anyway) which didn't have another usable solution. [*] People who want to use 'priorization' are usually confused and their actual problem is lack of resources. An example I have used to explain that in the past: Assuming twenty people were invited to a barbecue and, after all of them arrived, it was discovered that only ten steaks are available. There are two sensible solutions to this problem, namely, buy more steaks or divide the existing ones among the guests. And there is the 'electrical engineering approach': Shoot ten of the guests. For obvious reasons, nobody except electrical engineers considers this to be a viable option and even electrical engineers only do so if they are dealing with other people's guests. [**] My boss would presumably roast me on slowly on a small fire if I would make major efforts to support 'weird operating systems' because the code could theoretically also run there. Minor portability problems are best addressed once the code is actually in need of being ported. Lastly, I don't write "real-time applications" for systems which have nothing better to do than to uselessly copy 48K of data around for every I/O operations (simplified), with me being nevertheless convinced that this cannot possibly be something I am doing wrong.
From: Ersek, Laszlo on 5 May 2010 13:13 On Wed, 5 May 2010, Ian Collins wrote: > Try reading your man pages. I don't like to. I rather read the SUS. (I'm currently in a situation where this approach is feasible.) Thanks, lacos
From: Ersek, Laszlo on 5 May 2010 13:28 On Wed, 5 May 2010, Rainer Weikusat wrote: > I care for exactly two things wrt 'I/O multiplexing', namely 'can I > read data' and 'can I write pending data'. I have so far not found any > uses for 'TCP urgent data'[*]. (Neither have I -- I just wanted my port forwarder to support it, partly for telnet, partly for learning.) > I don't care for STREAMS. They are not supported on Linux and hence, > irrelevant for new code[**]. > [**] My boss would presumably roast me on slowly on a small > fire if I would make major efforts to support 'weird operating > systems' because the code could theoretically also run there. > Minor portability problems are best addressed once the code is > actually in need of being ported. I used to have different priorities. I guess that makes me overzealous towards portability. My apologies. > This implies that I use POLLIN and POLLOUT (when appropriate) for events > and usually map anything 'weird' which might be returned in revents to > POLLIN. If it is an EOF, read will detect that. The same is true for any > kind of error condition. (I kind of feel a contradiction between this and: ----v---- From davids(a)webmaster.com Wed May 5 12:49:19 2010 Date: Wed, 5 May 2010 03:49:19 -0700 (PDT) From: David Schwartz <davids(a)webmaster.com> Newsgroups: comp.unix.programmer Subject: Re: experienced opinions [snip] In fact, the only common error I see with select is thinking that 'poll' will return writability or readability if the connection closes or errors. And the only people expect this behavior, typically, is because it's what 'select' does. (Had they started out with 'poll', they likely wouldn't have expected this.) [snip] ----^---- but I rest my case.) > I have so far not had any problems which could have been solved by ppoll > (which exists on Linux, anyway) which didn't have another usable > solution. So there is a ppoll(); great! --o-- Thank you very much. I really appreciate this! lacos
From: Rainer Weikusat on 6 May 2010 07:40
"Ersek, Laszlo" <lacos(a)caesar.elte.hu> writes: > On Wed, 5 May 2010, Rainer Weikusat wrote: [...] >> and usually map anything 'weird' which might be returned in revents >> to POLLIN. If it is an EOF, read will detect that. The same is true >> for any kind of error condition. > > (I kind of feel a contradiction between this and: > > ----v---- > From davids(a)webmaster.com Wed May 5 12:49:19 2010 > Date: Wed, 5 May 2010 03:49:19 -0700 (PDT) > From: David Schwartz <davids(a)webmaster.com> > Newsgroups: comp.unix.programmer > Subject: Re: experienced opinions > > [snip] > > In fact, the only common error I see with select is thinking that > poll' will return writability or readability if the connection closes > or errors. [...] There is none. POLLHUP and POLLERR are two revents-only values which report possibly interesting connection state changes other than 'data to read available' or 'bufferspace to write data into available'. Since both errors and 'hangups' can occur during normal I/O operations, the respective input- and output-handlers need to be able to deal with these conditions, anyway, and there is no reason to care specially for either of both. Because of this, I usually do something like if (revents & ~(POLLIN | POLLOUT)) revents |= POLLIN; and let the ordinary input handler deal with it. |