[concurrency-interest] ForkJoinPool for async http calls?

Christian Essl christianessl at googlemail.com
Thu May 10 11:26:32 EDT 2012


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).

My main question therefore is as you stated:

> But if it is called on a fork join thread, could the system be smart
> enough to execute other tasks on the same thread until the origin task
> completes?

And I don't know.

Also thanks for the other hints regarding servlets

On Thu, May 10, 2012 at 4:43 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> My understanding of your question:
>
> ForkJoinTask.invoke() appears to be a blocking action and may suspend
> the current thread (by something like Object.wait()) if its exec()
> returns false.
>
> But if it is called on a fork join thread, could the system be smart
> enough to execute other tasks on the same thread until the origin task
> completes?
>
> That seems to be the case. However, in your example, it may create a
> very deep call stack:
> ...compute()...invoke()...compute()...invoke()...
>
> Your use of blocking invoke() is quite odd in an async program; I
> guess your reason is code simplicity. It's not a pleasant task to
> rewrite a single threaded blocking code into delicately linked async
> callbacks, when states and flows get complicated.
>
> P.S. servlet output stream is blocking anyway, you need a dedicated
> thread for every client when writing responses. My experience is that
> majority of threads in a servlet app are blocked on writing
> responses(big) to clients(slow). If you are really serious about async
> IO, servlet programming model doesn't fit. You need a real async Java
> web framework; to my knowledge today there is only Play! 2.0. (Or
> netty etc. if you don't need a web framework).
>
> Zhong Yu
>
> On Thu, May 10, 2012 at 7:12 AM, Christian Essl
> <christianessl at googlemail.com> wrote:
>> Hi Viktor,
>>
>> Thanks for your answer, and thanks for your patient discussion outside
>> of the mailing-list.
>>
>> As said I like the akka-framework, still it would be very nice if
>> anybody could answer my original question whether ForkJoinTasks can
>> give a sort of non-blocking future also suitable for async IO, because
>> I am stil not sure.
>>
>> Thanks,
>> Christian


More information about the Concurrency-interest mailing list