| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
| |
|
|\
| |
| |
| | |
No longer listens to dirs outside of the app directory.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
rails5 uses the listen gem to watch for changes from autoload directories
and from i18n directories. Changes there would be reflected by the
running app, in development mode usually.
However, files outside of the application directory or locally installed
gems should not change during development, and rails does not need to
reflect changes there if they do.
This change makes sure only those paths that do not originate from
the app itself are watched. This can help especially with the situation on
OSX, where rb-fsevent - which implements file watching - is quite a
resource hog.
|
| | |
|
|\ \
| | |
| | | |
Raise an error if FileUpdateChecker#execute is called with no block
|
| |/ |
|
|/ |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
|
|
|
|
|
| |
Some files like routes.rb may be very large and vary between the initialization of the app and the first request. In these scenarios if we are using a forked process we cannot rely on the files to be unchanged between when the code is booted and the listener is started.
For that reason we start a listener on the main process immediately, when we detect that a process does not have a listener started we force the updated state to be true, so we are guaranteed to catch any changes made between the code initialization and the fork.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need one file checker booted per process as talked about in #24990. Before we do a check to see if any updates have been registered by the listener we first check to make sure that the current process has booted a listener.
We are intentionally not starting a listener when the checker is created. This way we can avoid #25259 in which puma warns of multiple threads created before fork. As written the listener for each process will be invoked by the `ActionDispatch::Executor` middleware when the `updated?` method is called. This is the first middleware on the stack and will be invoked before application code is read into memory.
The downside of this approach is that the API is a little less obvious. I.e. that you have to call `updated?` to get the listener to start is not intuitive. We could make `boot!` not private if we want to make the API a little nicer. Alternatively we could boot when the checker is initialized however this reintroduces the puma threads warning, and also means that in cases of `rails server` or when using `preload!` that we have extra threads notifying of changes on a process that we don't care about.
[close #24990] [close #25259]
|
|
|
|
|
| |
Slight refactor to improve boot performance on some Ruby
implementations (for now).
|
| |
|
|
|
|
|
|
| |
These should allow external code to run blocks of user code to do
"work", at a similar unit size to a web request, without needing to get
intimate with ActionDipatch.
|
|
|
|
| |
See the rationale in the comment present in this patch.
|
|
Better English.
|