experienced opinions
in [Unix Programming]
|
From: David Schwartz on 4 May 2010 14:38 On May 4, 2:00 am, boltar2...(a)boltar.world wrote: > >And many of these techniques outperform 'select' or 'poll' even when > >the number of descriptors is small, so the only downside is usually > >added implementation complexity. Also important, the worst-case > >behavior of these mechanisms is *way* better than 'select' or 'poll'. > Anyone who has a program that is dealing with thousands of descriptors > should really think about going multiprocess or multithreaded. A single > threaded program dealing with that many descriptors sounds like a recipe > for inefficient processing. Right, but whether you use multiple processes, multiple threads, or a single thread, you still have to discover which sockets you need to do I/O on somehow. DS
From: Ian Collins on 4 May 2010 22:46 On 05/ 5/10 12:41 AM, Ersek, Laszlo wrote: > On Tue, 4 May 2010, boltar2003(a)boltar.world wrote: > >> Try explaining to someone new that to use poll they'll have to do >> their own memory management or artificially limit the number of >> descriptors they'll use. > > My problem with poll() is this: > > POLLIN - Data other than high-priority data may be read without blocking. > POLLRDNORM - Normal data may be read without blocking. > POLLRDBAND - Priority data may be read without blocking. > POLLPRI - High-priority data may be read without blocking. > POLLOUT - Normal data may be written without blocking. > POLLWRNORM - Equivalent to POLLOUT. > POLLWRBAND - Priority data may be written. > > What's the difference between POLLIN and POLLRDNORM? (Especially wrt. > POLLOUT being equivalent to POLLWRNORM.) And how does POLLRDBAND differ > from POLLPRI? How do they all map to normal TCP payload as opposed to > urgent bytes? What is the effect of POLLWRBAND on TCP, since select() > doesn't offer an fd_set for writing "exceptional data"? Try reading your man pages. -- Ian Collins
From: David Schwartz on 5 May 2010 00:39 On May 4, 10:01 am, "Ersek, Laszlo" <la...(a)caesar.elte.hu> wrote: > I see your point. It's wrong. 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? I'm setting up my argument > for refutation by stating it as a fact. That should elicit more responses > from subscribers than asking questions. (Which I also did ask.) Instead of > disproving my post by describing poll()'s portably correct usage, you > accuse me of malice. As I recall, 'select' actually takes three FD sets. Does anyone know precisely what that third set is for? DS
From: boltar2003 on 5 May 2010 05:12 On Tue, 04 May 2010 17:00:07 +0200 Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote: >I am honestly convinced that you (and the Boltar-person) are trying to >make up complicated problems based on hypothetical possibilities where >none actually exist in order to distract from the discussion of the >properties of different kinds of 'synchronous I/O multiplexing >interfaces' whose contents would otherwise not be completely favorable >regarding a solution both of you happen to prefer. And my 'comment' Actually I was just telling my point of view. I'm sorry if you have a problem with people disagreeing with you. I'm glad I don't have to work with people like you who think they know everything and are convinced they're always right. B2003
From: Rainer Weikusat on 5 May 2010 06:15
boltar2003(a)boltar.world writes: > On Tue, 04 May 2010 17:00:07 +0200 > Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote: >>I am honestly convinced that you (and the Boltar-person) are trying to >>make up complicated problems based on hypothetical possibilities where >>none actually exist in order to distract from the discussion of the >>properties of different kinds of 'synchronous I/O multiplexing >>interfaces' whose contents would otherwise not be completely favorable >>regarding a solution both of you happen to prefer. And my 'comment' > > Actually I was just telling my point of view. > I'm sorry if you have a problem with people disagreeing with > you. I'm glad I don't have to work with people like you who think > they know everything and are convinced they're always right. An observation I have made in the past is that people tend to 'find' their own vices in others. |