About Blocking operation

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

About Blocking operation

saikon
1. why ratpack back to original compute thread after Blocking.get invoked? can it select any of compute thread in pool from ExecControl? what it benifit? I guess, it will reuse the same CPU cacheline and reduce context switch? but when blocking operation is not fast enough the cache line will restore and netty is not  implement java-thread-affinity,right?
      2. In blocking executor, the docs says "Performing computation during the operation will degrade performance" ,it means when do compution in blocking thread it will make it spend more time and can't quikcly react by another blocking request and increase the num of blocking thread in cachedThreadPool?
      3. also about blocking operation, "Blocking.on(Promise)"  will lock  and waiting the async value which throw to eventLoop,then continue. Now that we've got the lock why don't let the promise execution  in  this blocking thread?  it will take extra time to waiting eventloop  dispatch and context switch for this "throw" than just execution in this blocking thread, in my stupid opinion
Reply | Threaded
Open this post in threaded view
|

Re: About Blocking operation

saikon
about(1)I make a stupid misstake, a request binding a channel which also binding a eventloop ,change another eventloop will miss the channel... I too focus on thread model to ignore the channel, what a stupid mistake... (2)(3) is available :D
Reply | Threaded
Open this post in threaded view
|

Re: About Blocking operation

danveloper
Administrator
Hi Saikon:

saikon wrote
2. In blocking executor, the docs says "Performing computation during the operation will degrade performance" ,it means when do compution in blocking thread it will make it spend more time and can't quikcly react by another blocking request and increase the num of blocking thread in cachedThreadPool?
Computation threads are created with higher priority than blocking threads, so you should avoid doing any computation in blocking threads. The basic idea as well is you want the blocking thread to exit as soon as it is done performing its I/O bound work.

saikon wrote
3. also about blocking operation, "Blocking.on(Promise)"  will lock  and waiting the async value which throw to eventLoop,then continue. Now that we've got the lock why don't let the promise execution  in  this blocking thread?  it will take extra time to waiting eventloop  dispatch and context switch for this "throw" than just execution in this blocking thread, in my stupid opinion
For the same reason as above, amongst others. We want Promise based work to be executed on the thread pool that most makes sense, so the Blocking.on fixture allows a new execution to process a Promise stream and wait for its completion. This is the most efficient way to schedule work throughout your application.
Reply | Threaded
Open this post in threaded view
|

Re: About Blocking operation

saikon
This post was updated on .
Hi dan,
you means compute thread has high priority when compete CPU schedule-time with blocking thread,so we must do only its bound (IO) work in blocking thread avoid its schedule-out when execution,right?

Another question, why ratpack don't use single eventloop as boss-Group for acceptor than use compute thread its self ?