concurrent-ruby icon indicating copy to clipboard operation
concurrent-ruby copied to clipboard

Modern concurrency tools including agents, futures, promises, thread pools, supervisors, and more. Inspired by Erlang, Clojure, Scala, Go, Java, JavaScript, and classic concurrency patterns.

Results 59 concurrent-ruby issues
Sort by recently updated
recently updated
newest added

* To fix the Ruby 3.3.5 warnings: https://github.com/ruby-concurrency/concurrent-ruby/issues/1061 * concurrent-ruby only uses 7 constants from Logger, so just copy those over. This should be fully compatible and address the warnings....

Running railties test suite with Ruby 3.3.5, I observer following failures due to warning which appears to come from concurrent-ruby: ~~~ * Test file: test/application/bin_setup_test.rb /usr/share/gems/gems/concurrent-ruby-1.1.9/lib/concurrent-ruby/concurrent/concern/deprecation.rb:1: warning: logger was loaded...

As the title says, it's just a simple removal of duplicate require file

Closes https://github.com/ruby-concurrency/concurrent-ruby/issues/1066 Closes https://github.com/ruby-concurrency/concurrent-ruby/issues/1075 Alternative to https://github.com/ruby-concurrency/concurrent-ruby/pull/1079 Implementation is based on the discussion in the linked issues.

In the Ruby implementation: ```ruby require 'concurrent' puts "Thread Count: #{Thread.list.count}" pool = Concurrent::CachedThreadPool.new( min_threads: 0, max_threads: 5, idletime: 1 ) puts "Thread Count: #{Thread.list.count}" # we have 1 thread...

``` * Operating system: macOS Sequoia 15.0.1 * Ruby implementation: ruby 3.4.0preview1 * `concurrent-ruby` version: 1.3.3 * `concurrent-ruby-ext` installed: no * `concurrent-ruby-edge` used: no ``` Cross-post of https://github.com/rails/rails/pull/53211 to open...

``` * Operating system: mac * Ruby implementation: Ruby * `concurrent-ruby` version: 1.3.4 * `concurrent-ruby-ext` installed: no * `concurrent-ruby-edge` used: no ``` The docs for ThreadPoolExecutor#kill suggest that inflight tasks...

This resolves #1069. However, I'm still not 100% sure if the `RubySingleThreadExecutor` is *actually* serialized. From my understanding of the code, it is, but there may be edge-cases I'm missing...

In 455203e, the `RubySingleThreadExecutor` implementation was updated to use the generic `RubyThreadPoolExecutor`. With that change, the previously included `SerialExecutorService` module was removed, resulting in `RubySingleThreadExecutor#serialized?` now returning `false`. I'm wondering...