You're talking about polling via a select(...)? It's not really polling (although it's not asynchronous callbacks) -- the select wakes up when there's an event ready to service, and it sleeps forever (or until the specified timeout) if there's no event. You can also handle udp & tcp in the same select, so no need for two threads. LimeWire uses a single thread for all its I/O and works quite well.
Sam On 10/30/06, Lemon Obrien <[EMAIL PROTECTED]> 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." <[EMAIL PROTECTED]> 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
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
