[#107430] [Ruby master Feature#18566] Merge `io-wait` gem into core IO — "byroot (Jean Boussier)" <noreply@...>
Issue #18566 has been reported by byroot (Jean Boussier).
22 messages
2022/02/02
[ruby-core:107405] [Ruby master Feature#16663] Add block or filtered forms of Kernel#caller to allow early bail-out
From:
"jeremyevans0 (Jeremy Evans)" <noreply@...>
Date:
2022-02-01 01:39:50 UTC
List:
ruby-core #107405
Issue #16663 has been updated by jeremyevans0 (Jeremy Evans).
headius (Charles Nutter) wrote in #note-25:
> Is there a way to prohibit the `to_enum` form? I don't think it will be useful to support since it may vary greatly across implementations (depending on what the stack looks like and what gets included).
I don't know of a way to do this. I don't think the method being called can tell whether it is being run via an enumerator or not. In CRuby, you could probably override `to_enum`, check if the method being called is a C method using the same C function, and fail in that case, but that's trivial to work around be rebinding the Kernel `to_enum` method.
> It does raise a question for me, though... is your patch eagerly capturing the stack? I have been trying to figure out how the stack trace is identical in both the block form and the to_enum form and it seems like the trace would have to have been captured at the same level, rather than at the point the enum starts to run.
It isn't identical. From the tests:
```ruby
cllr = caller_locations(1, 2); ary = Thread.to_enum(:each_caller_location).to_a[2..3]
assert_equal(cllr.map(&:to_s), ary.map(&:to_s))
```
The `[2..3]` shows there are extra entries in the `to_enum` case.
----------------------------------------
Feature #16663: Add block or filtered forms of Kernel#caller to allow early bail-out
https://bugs.ruby-lang.org/issues/16663#change-96305
* Author: headius (Charles Nutter)
* Status: Open
* Priority: Normal
----------------------------------------
There are many libraries that use `caller` or `caller_locations` to gather stack information for logging or instrumentation. These methods generate an array of informational stack frames based on the current call stack.
Both methods accept parameters for `level` (skip some number of Ruby frames) and `length` (only return this many frames). However many use cases are unable to provide one or both of these.
Instrumentation uses, for example, may need to skip an unknown number of frames at the top of the trace, such as to dig out of rspec plumbing or active_record internals and report the first line of user code. In such cases, the typical pattern is to simply request *all* frames and then filter out the one that is desired.
This leads to a great deal of wasted work gathering those frames and constructing objects to carry them to the user. On optimizing runtimes like JRuby and TruffleRuby, it can have a tremendous impact on performance, since each frame has a much higher cost than on CRuby.
I propose that we need a new form of `caller` that takes a block for processing each element.
```ruby
def find_matching_frame(regex)
caller do |frame|
return frame if frame.file =~ regex
end
end
```
An alternative API would be to allow passing a query object as a keyword argument, avoiding the block dispatch by performing the match internally:
```ruby
def find_matching_frame(regex)
caller(file: regex)
end
```
This API would provide a middle ground between explicitly specifying a maximum number of stack frames and asking for all frames. Most common, hot-path uses of `caller` could be replaced by these forms, reducing overhead on all Ruby implementations and drastically reducing it where stack traces are expensive.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>