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 <[EMAIL PROTECTED]>/* 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
