[#116016] [Ruby master Bug#20150] Memory leak in grapheme clusters — "peterzhu2118 (Peter Zhu) via ruby-core" <ruby-core@...>
Issue #20150 has been reported by peterzhu2118 (Peter Zhu).
7 messages
2024/01/04
[#116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>
Issue #20205 has been reported by byroot (Jean Boussier).
77 messages
2024/01/23
[ruby-core:116007] [Ruby master Feature#20102] Introduce `Fiber#resuming?`
From:
"Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>
Date:
2024-01-04 09:46:13 UTC
List:
ruby-core #116007
Issue #20102 has been updated by Eregon (Benoit Daloze).
ioquatix (Samuel Williams) wrote in #note-4:
> @Eregon I appreciate your input. I don't mind doing that, but isn't that the same for all methods on Fiber?
It is, and many methods on Fiber are already not allowed to be called for Fiber belonging to other threads (e.g. resume/transfer/storage/...).
Since we are adding a new method, we might as well encourage correct usage and discourage incorrect usage (+ it means the state for resuming does not need to become `volatile` which would be bad for performance).
> In other words, the GVL provides a bit of a safety net.
It does not, the GVL could be released e.g. just after `resuming?` is done but before the caller gets the value and handle it.
----------------------------------------
Feature #20102: Introduce `Fiber#resuming?`
https://bugs.ruby-lang.org/issues/20102#change-106001
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Assignee: ioquatix (Samuel Williams)
----------------------------------------
There are some tricky edge cases when using `Fibre#raise` and `Fiber#kill`, e.g.
```ruby
fiber = nil
killer = Fiber.new do
fiber.raise("Stop")
end
fiber = Fiber.new do
killer.resume
end
fiber.resume
# 4:in `raise': attempt to raise a resuming fiber (FiberError)
# 4:in `block in <main>'
```
Async has to deal with this edge case explicitly by rescuing the exception:
https://github.com/socketry/async/blob/ffd019d9c1d547926a28fe8f36bf7bfe91d8a168/lib/async/task.rb#L226-L233
I'd like to avoid doing that and instead just ask "Can I kill/raise on this fiber right now?" which is determined by whether the fiber itself can be resumed or transferred to.
To address this, I'd like to introduce `Fiber#resuming?`:
```c
/*
* call-seq: fiber.resumed? -> true or false
*
* Whether the fiber is currently resumed.
*/
VALUE
rb_fiber_resuming_p(VALUE fiber_value)
{
struct rb_fiber_struct *fiber = fiber_ptr(fiber_value);
if (FIBER_TERMINATED_P(fiber)) return RUBY_Qfalse;
return RBOOL(fiber->resuming_fiber);
}
```
See the PR: https://github.com/ruby/ruby/pull/9382
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- ruby-core@ml.ruby-lang.org
To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/