[concurrency-interest] ForkJoinPool for async http calls?

Gregg Wonderly gergg at cox.net
Thu May 10 15:30:43 EDT 2012


In the end we need to really do data flow analysis and schedule CPU use based on the optimizations which the analysis reveals.  The EMSP project at Bell Labs which was supporting advanced image processing for submarine radar systems, during the cold war, seems to be completely lost technology in the private sector...

Who knows what's possible now with the convenience of FPGS and modern DSP systems!

Gregg Wonderly

Sent from my iPhone

On May 10, 2012, at 1:39 PM, "William Louth (JINSPIRED.COM)" <william.louth at jinspired.com> wrote:

> threads they are great...they get work done...we should have more of that in the world ;-)
> 
> on an ever so slightly more serious note they offer the nearest     thing we have to a consistent causality and context of execution     that today is able to span whatever framework or jvm language you are using except for of course...blahblah..though admittedly this is transient (but what is not) threads also serve as a more appropriate self observation (reflection) point and self regulation (constructional) mechanism though naturally you could re-implement (and copy) this stuff (and context) countless times up and down the stack in whatever inefficient manner you care for
> 
> On a more serious note I refer you to http://bytemunch.com/post/nodejs-is-bad-ass-rock-star-tech-xtranormal/
> 
> threads are the nearest thing we have to identifiable (explicit) network flows...we have just failed to capitalize on this and bring more dynamic service classification, contextual prioritization, policing, shaping,...that would work irrespective of VM language or library or fadofthedayframework http://www.infoq.com/articles/QoS-for-Applications
> 
> On 10/05/2012 19:13, √iktor Ҡlang wrote:
>> 
>> 
>> 
>> On Thu, May 10, 2012 at 7:07 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>> On Thu, May 10, 2012 at 10:26 AM, Christian Essl
>> <christianessl at googlemail.com> wrote:
>> > Your are right my primary concern is code-simplicity not pure
>> > performance, basicly writing in a traditional imperative blocking
>> > style but still having IO with (mostly) non-blocking threads (and no
>> > callbacks, no monadic futures).
>> 
>> Thread is such a nice programming abstraction, it's a shame that we
>> are so concerned of its overhead nowadays. Replacing simple threads
>> with complex tasks seems to be retrogressing - aren't programming
>> supposed to become easier?
>> 
>> What are the fundamental reasons that Java Threads are           expensive?
>> 
>> Can you give some arguments as to the greatness of proactive programming (threads)?
>>  
>> 
>> Zhong Yu
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>> 
>> 
>> 
>> -- 
>> Viktor Klang
>> 
>> Akka Tech Lead
>> Typesafe - The software stack for applications that scale
>> 
>> Twitter: @viktorklang
>> 
>> 
>> 
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120510/2d2a4998/attachment.html>


More information about the Concurrency-interest mailing list