[concurrency-interest] ForkJoinPool for async http calls?

√iktor Ҡlang viktor.klang at gmail.com
Thu May 10 15:18:44 EDT 2012


Lets pretend it isn't. Examples please.
On May 10, 2012 9:15 PM, "William Louth (JINSPIRED.COM)" <
william.louth at jinspired.com> wrote:

>
>
> It's "self" explanatory.
>
> On 10/05/2012 20:49, √iktor Ҡlang wrote:
>
> Examples please.
> On May 10, 2012 8:47 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 <http://www.typesafe.com/>Â - The software stack for
>> applications that scale
>>
>> Twitter: @viktorklang
>>
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://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
>>
>>
> _______________________________________________
> 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/0e6eae70/attachment-0001.html>


More information about the Concurrency-interest mailing list