Project

General

Profile

Actions

Bug #18474

closed

938e027c seems to have caused a regression in yield handling with concurrent-ruby

Added by aaronjensen (Aaron Jensen) about 2 years ago. Updated about 2 years ago.

Status:
Closed
Assignee:
-
Target version:
-
[ruby-core:107053]

Description

I'm sorry for the awful title, I don't know enough about what is going on to describe it better. From a debugging perspective it seems that a very specific set of circumstances causes a begin block to be jumped out of when a proc it is calling yield, without anything being rescuable. An ensure block will be evaluated, if added, but nothing after that. This is begin block: https://github.com/ruby-concurrency/concurrent-ruby/blob/52c08fca13cc3811673ea2f6fdb244a0e42e0ebe/lib/concurrent-ruby/concurrent/executor/safe_task_executor.rb#L23-L29

For reference, see this issue: https://github.com/ruby-concurrency/concurrent-ruby/issues/931

I have a repro here: https://github.com/aaronjensen/concurrent-repro

It requires concurrent-ruby. Someone better versed than me may be able to create a repro without it, but there is a lot going on in concurrent-ruby.

Everything in the repro seems to be required, to_a.first works, but first does not for example.


Related issues 4 (0 open4 closed)

Related to Ruby master - Feature #17613: Eliminate useless catch tables and nops from lambdasClosedActions
Related to Ruby master - Bug #18475: Yielding an element for Enumerator in another thread dumps coreClosedActions
Related to Ruby master - Bug #18637: Segmentation fault for yield inside another ThreadClosedActions
Related to Ruby master - Bug #18649: Enumerable#first breaks out of the incorect block when across threadsClosedActions
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0