Start on a guide for the Executor & Load Interlock #27494

Open
wants to merge 1 commit into
from

Projects

None yet

7 participants

@matthewd
Member

No description provided.

@matthewd matthewd Start on a guide for the Executor & Load Interlock
05fce0a
@jrochkind
Contributor

Nice, thanks. The existing Autoloading and Reloading Constants might need a lookover, or at minimum a cross-link to this one.

+end
+```
+
+NOTE: Concurrent Ruby uses a `ThreadPoolExecutor`, which it sometimes configures
@tomkadwill
tomkadwill Dec 30, 2016 Contributor

s/configures/configured/

@turboladen
turboladen Jan 5, 2017

"configures" seems ok here, no? Or does it not do this anymore?

+
+Only long-running "top level" processes should invoke the Reloader, because if
+it determines a reload is needed, it will block until all other threads have
+completed and left any Executor block.
@tomkadwill
tomkadwill Dec 30, 2016 Contributor

s/block/blocks/

@jrochkind
jrochkind Jan 2, 2017 Contributor

suggest : "A Rails web app process takes care of invoking the Reloader for you under normal use." or similar.

+ # call application code here
+end
+```
+
@jrochkind
jrochkind Dec 30, 2016 Contributor

I believe the Reloader is not re-entrant? Since you mentioned the executor is (thanks!), can you specify whether reloader is or is not intended to be?

@matthewd
matthewd Dec 30, 2016 Member

It is.. I'm just not expecting that you'd use it in a place it matters:

The reloader (because, by design, it can change the application out from under you) is only really appropriate when you're in control, which implies you know how you got here / whether it's already been invoked.

The executor, OTOH, is fine to casually wrap around anything that strikes your fancy, "just in case" it isn't in play yet. Thus it seemed more important to address reentrancy, on the basis it's a concern a potential caller is likely to have.

Anyway, will clarify 👍🏻

@jrochkind
jrochkind Jan 2, 2017 Contributor

awesome, this reply is helpful, recommend wrapping it into the guide more explicitly too.

+* enable and disable the Active Record query cache
+* return acquired Active Record connections to the pool
+* constrain internal cache lifetimes
+
@jrochkind
jrochkind Jan 2, 2017 Contributor

This Guide is great, thanks. Can you reference or link to where these callbacks are set up for default Rails app?

+ -
+ name: Threading and Code Execution in Rails
+ url: threading_and_code_execution.html
+ description: This suige describes the considerations needed and tools available when working directly with concurrency in a Rails application.
@rosenfeld
rosenfeld Jan 3, 2017 Contributor

minor typo here: suige => guide

+If it's impractical to physically wrap the application code in a block (for
+example, the Rack API makes this problematic), you can also use the `run!` /
+`complete!` pair.
+
@noahgibbs
noahgibbs Jan 5, 2017

Would be a great idea to have a small example here, something like:

Thread.new do
  begin
    Rails.application.executor.run!
      # your code here
  ensure
    Rails.application.executor.complete!
  end
end
+
+Threaded Active Job adapters, including the built-in Async, will likewise
+execute several jobs at the same time. Action Cable channels are managed this
+way too.
@noahgibbs
noahgibbs Jan 5, 2017

This seems like as long as an Action Cable connection exists, reloading constants can't happen since the other threads will block (reasonable.) If that's true, is it worth mentioning it explicitly at some point, so that doesn't surprise people?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment