From: eregontp@...
Date: 2020-12-05T12:53:43+00:00
Subject: [ruby-core:101252] [Ruby master Bug#17369] Introduce non-blocking `Process.wait`, `Kernel.system` and related methods.

Issue #17369 has been updated by Eregon (Benoit Daloze).


Does such code still work, with a scheduler?
```ruby
`echo foo`
p $? # => #<Process::Status: pid 43525 exit 0>
```

If not, it seems a significant problem, as existing would break with a scheduler.

Given the implementation in the test scheduler:
```ruby
  def process_wait(pid, flags)
    # This is a very simple way to implement a non-blocking wait:
    Thread.new do
      Process::Status.wait(pid, flags)
    end.join
  end
```
It sounds like you would need a way to set `$?` on the current Thread.
So that `$?` can be set for the caller.
I think that's fine to add.

I think `$?` should be Fiber-local, probably it's thread-local only for historic reasons.
Otherwise, just switching between Fibers (e.g., on IO) would expose the `$?` of other Fibers, which will lead to bugs.
I expect that change to cause extremely few compatibility issues (`$~`, etc are already fiber-local + frame-local).

----------------------------------------
Bug #17369: Introduce non-blocking `Process.wait`, `Kernel.system` and related methods.
https://bugs.ruby-lang.org/issues/17369#change-88929

* Author: ioquatix (Samuel Williams)
* Status: Assigned
* Priority: Normal
* Assignee: ioquatix (Samuel Williams)
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
https://github.com/ruby/ruby/pull/3852

This PR introduces optional hooks to the scheduler interface for handling `Process.wait`, `Kernel.system` and other related methods (`waitpid`, `wait2`, etc).

It funnels all methods through a new interface `Process::Status.wait` which is almost identical to `Process.wait` except for several key differences:

- The return value is a single instance of `Process::Status`.
- It does not set thread local `$?`.

This is necessary for keeping the scheduler interface simple (and side effects are generally bad anyway).



-- 
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>