That's not really a poll -- it's just a limit on the select. There's many valid reasons to add a timeout to select, such as keeping a separate list of 'timeoutable' items -- that is, items which will timeout after a certain period of time. If you want to manage all I/O in a single thread (which can include timing things out), then it makes perfect sense to only block in a select call for a certain period of time (that period being the next time which a timeout or other scheduled event will happen). The select will still wake up the moment a descriptor is ready for reading/writing/accepting/connecting, but it will also wake up when any other event is ready to be processed. (We not only limit it based on timeoutable things, but also based on the next time at which any non-blocking throttle has more data that can be processed, or an I/O-related scheduled event is scheduled, etc...).
Polling (atleast polling as I understand it) would be periodically asking if there are any read/write/connect/accept events that need handling. That's bad, and will dramatically reduce throughput. So long as nothing in your I/O thread blocks, using select with a timeout will scale incredibly well and have very high throughput. Sam On 10/31/06, Lemon Obrien <[EMAIL PROTECTED]> wrote:
I'm thinking of polling as in calling select with a timeout limit. a non-blocking call. Daniel Stutzbach <[EMAIL PROTECTED]> wrote: I think you are confusing polling with calling poll(). Despite the name, poll() does not do polling. It blocks until one of a set of file descriptors becomes ready, then tells you which ones. select() does the same thing with slightly different semantics. poll() is good. Polling, on the other hand, is almost always bad. On 10/30/06, Lemon Obrien wrote: > "polling" -- polling is a good thing with p2p; LimeWire is trying to do > polling; it reduces the number of threads...if you do one for udp, another > for tcp, and another for network maintance, you already have three threads > running; not even counting inteface...or any thread you'll have to spawn to > do udp transfers, or searches... > > yes i know "polling" is not the attractive way to create a server...but...in > this case; i believe it's preffered. > > just my opinion. > > "Chaz." wrote: > I think your are confused about ACE. It might be single threaded but it > doesn't using polling. Instead it uses event based scheduling and state > machines. It is a very sophisticated, low overhead system. Check it out > before "dissing" it. > > In the python arena Twisted is a single thread, event passed framework > and the BitTorrent client is written using it. I have also written an > application using it that have 5 services running at once and is a very > sophisticated p2p application (supporting multiple requests at once). > > The reason I mentioned ACE at the start of all this was to point out you > can really make a sophisticated, high performance application without > much effort. > > Chaz > > Lemon Obrien wrote: > > you're speaking to people who have 15 years plus experience...i > > persoannly started coding professionally in 92, two years before the > > internet. > > > > abstraction layer. abstraction layer...if it took a whole team to create > > ACE, Twisted, Whatever,...with years of testing...well; that's probably > > a case where too many cooks are in the kitchen...and after looking at > > ACE architecture...not to be harsh; but it looked disorganized; and > > seemed to suck...plus someone mention "single threaded" p2p and "single" > > threaded systems don't mix. > > > > anyway...i don't believe in following rules laid down by IT people who > > do nothing but sit in cubicles. > > > > */Antoine Pitrou /* wrote: > > > > > > Le jeudi 26 octobre 2006 à 12:28 -0700, Alex Pankratov a écrit : > > > But average Linux/Windows coder with a good understanding of language > > > standards (assuming C/C++) should be able to produce non-UI > > abstraction > > > layer *much* faster than it would take him to learn something like > > ACE. > > > > Wow, it's a joke right? > > > > I can't help thinking how tedious it must be to workaround all the > > various subtleties of each platform's network stack, API, threading > > semantics etc. There is a reason why people decided to write ACE, > > Twisted, apr... in the first place. > > > > Not to mention that software like ACE or Twisted has been in use and > > actively maintained for years, and chances are they make the right > > decisions in a lot of places. Not because their designers are genious, > > but because they have actually been tested and fixed to work correctly > > in a *lot* of situations. > > > > What are the odds that an "average Linux/Windows coder" would be able to > > come up with the right decisions at the first attempt to code an network > > abstraction library? At what cost? > > Perhaps "average coder" has a special meaning in your mouth, because I > > can't imagine how your claim can be realistic. > > > > Oh and by saying "Linux/Windows", you already leave out the BSDs, MacOS > > X, and various other OS flavours (embedded stuff, etc.). > > > > > > > Project leader who pushed for using ACE had no better option > > > than to suggest purchasing paid support from ACE people. > > > > And how is that a problem exactly? Does your in-house "average coder" > > work for free? > > > > If the same bug had occurred with an in-house developed library, who > > could you have paid to solve the problem? > > Answer: nobody, because nobody outside knows your library, and the guy > > who coded is an "average coder" by your own words, so he would have a > > very hard time debugging bizarre, erratic threading issues. > > > > The very fact that you could find someone to fix that - probably > > specific or exotic - problem is highly positive. > > > > regards > > > > Antoine. > > > > > > _______________________________________________ > > p2p-hackers mailing list > > [email protected] > > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > > > > > > > You don't get no juice unless you squeeze > > Lemon Obrien, the Third. > > > > http://www.tamago.us > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > p2p-hackers mailing list > > [email protected] > > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > You don't get no juice unless you squeeze > Lemon Obrien, the Third. > > http://www.tamago.us > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > -- Daniel Stutzbach Computer Science Ph.D Student http://www.barsoom.org/~agthorr University of Oregon _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers You don't get no juice unless you squeeze Lemon Obrien, the Third. http://www.tamago.us _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
