Re: Asynchronous

[Robert Graham <robert_david_graham () yahoo com>]

I was worried about the programmer skill issue when ISS bought Network ICE. My code was top-to-bottom radically 
asynchronous in a language (C) that wasn't really built for asynchronous programming. The question was: when ISS took 
over the code, could their programmers handle it? The answer was 'yes'. Once they got over their initial discomfort 
(such as wanting to wrap everything in a C++ pure virtual interface class), they really got into it, and even made 
improvements I hadn't considered. The basic issue is practice, practice, practice. Once a programmer practices it, the 
paradigm becomes natural, and debugging it isn't a problem.

Or, you can exploit the fact that is now a lot of stuff out there (e.g "Stackless Python") that wraps the problem, 
giving you what appears to be a synchronous interface on top, but is really asynchronous underneath. One good example 
is the work Azul has put into their JVM for massively multicore x86 servers. It allows you to write what appear to be 
synchronous threads but which are fully asynchronous underneath, providing massive scalability that would otherwise 
take a hundred systems.

Azul is a good demonstration of a simple fact: we've largely solved the problem of synchronous programming, now we are 
working on multi-core programming. In the past, if you used a blocking socket or select(), you were doing it wrong. 
Now, if you use a pthread_mutex(), you are doing it wrong. By "doing it wrong", I mean "massive retraining of 
programmers to make them unlearn what they were taught in college".

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