Re: Asynchronous

[Sebastian Krahmer <krahmer () suse de>]

Basically, if you have good async code your state machine
ends up to be 'just' the most performing scheduler you could have
for your code. No kernel scheduler could have such performance
if you'd use threads. Just think of your async code being a lot of threads
scheduled by your FSM and just keeping the state you really need, no extra memory,
no libs etc. I think theres plenty of papers written about it
("The C10K problem") and you actually can debug it quite well.
(I think other programmers would say debugging exploits its hard,
it always depends on your daily work.)

Sebastian


On Wed, Oct 05, 2011 at 12:38:02PM -0400, Dave Aitel wrote:
> So while I'm in the process of running a large asynchronous event-driven
> product in a VM in another window, it's a good time to read all sorts of
> things about asynchronous programming.
>
> Frankly, I'm not a huge fan of it, but Chris is, and he's a better
> programmer than me, so we'll leave it at that. Largely, I think people
> are fans of Async because most languages and kernels are terrible at
> threads. Python, for example, does not have threads. "No worky worky",
> as we say around here.
>
> The downside of async is that it is basically impossible to debug, and
> you need a programmer as good as Chris to even begin to use it well.
> Likewise, the locking/blocking problems don't go away, they just get
> mapped into a more inscrutable form.
>
> So for systems that have working threads, you use them for anything
> IO-heavy (aka, web servers/crawlers/other useful hacking tools). But
> since almost no system HAS working, scalable, threads, people get
> excited about async.  And then you spend your whole life saying "Hey,
> this thing I do sometimes has to do a lot of work on the CPU, so let's
> put it in another thread please". Or "Hey, this whole giant DB library
> we have to use isn't built from the ground up to use Async, so we need
> it to be in its own thread and manage a feeder Queue to it".
>
> And then eventually you're like "Why on earth am I spending so much time
> worrying about how efficient an algorithm that runs on one machine is?"
> and you go off and build something that scales horizontally onto
> multiple machines. (Where "multiple" is > 100).
>
> But in the meantime you have things like asyncore and Node.js and stuff.
> I can't do them justice, but these posts below are the funniest thing
> you'll read since Steve Yegge <http://steve-yegge.blogspot.com/>.
>
> http://teddziuba.com/2011/10/node-js-is-cancer.html
> http://teddziuba.com/2011/10/straight-talk-on-event-loops.html
> http://www.unlimitednovelty.com/2011/10/nodejs-has-jumped-shark.html
>
> -dave
>
> -- 
> INFILTRATE 2012 January 12th-13th in Miami - the world's best offensive information security conference.
> www.infiltratecon.com



> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunityinc com
> https://lists.immunityinc.com/mailman/listinfo/dailydave


-- 

~ perl self.pl
~ $_='print"\$_=\47$_\47;eval"';eval
~ krahmer () suse de - SuSE Security Team

---
SUSE LINUX Products GmbH,
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany

_______________________________________________
Dailydave mailing list
Dailydave () lists immunityinc com
https://lists.immunityinc.com/mailman/listinfo/dailydave