Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Mar 27 14:47
    andrykonchin commented #905
  • Mar 27 14:21
    andrykonchin opened #905
  • Mar 23 18:02
    totrash commented #882
  • Mar 19 20:53
    pitr-ch commented #899
  • Mar 19 20:47
    pitr-ch closed #903
  • Mar 19 20:47
    pitr-ch commented #903
  • Mar 12 03:17
    jcavalieri commented #903
  • Mar 12 02:26
    jcavalieri commented #903
  • Mar 11 21:19
    pitr-ch commented #903
  • Mar 11 21:08
    pitr-ch labeled #903
  • Mar 11 21:05

    pitr-ch on master

    CI: Update latest JRuby to 9.2.… CI: Use latest JRuby … CI: Use jruby- and 1 more (compare)

  • Mar 11 21:05
    pitr-ch closed #901
  • Mar 11 21:05
    pitr-ch commented #901
  • Mar 11 21:03

    pitr-ch on master

    Fixed documentation for Concurr… Update doc Merge pull request #904 from ks… (compare)

  • Mar 11 21:03
    pitr-ch closed #904
  • Mar 11 21:02
    pitr-ch synchronize #904
  • Mar 10 17:44
    ksapozhnikov edited #904
  • Mar 10 16:03
    ksapozhnikov opened #904
  • Mar 06 21:41
    jcavalieri commented #903
  • Mar 06 20:41
    jcavalieri opened #903
Aditya C S
closing the channels will stop the loop and selection. However, the Channel.go thread will always remain active
Ben Sheldon (he/him)
@adityacs hi! I don't have much experience with channels, but I have two questions:
  1. Have you verified the loop is broken? For example, by puts-ing a message after the loop-end. I don't see an block-breaking return or throw in what you posted.
  2. Concurrent ruby typically runs things on a global thread pool that will manage, reuse and recycle threads on its own. So if you're confident that the thread isn't doing any work, it shouldn't need to be actively killed.
Aditya C S
@bensheldon_twitter Yeah, the loop is broken and thread is not doing any work
Tomek Wałkuski
Hi all! Do you recommend any resources on testing Async and TimerTask enabled classes?
Ben Sheldon (he/him)
@tomekw hi! I didn't find sources in testing, but I went towards integration testing. You could probably extract and test the task method themselves. Here's what I did with RSpec if your curious:

Hi all. I have a problem when converting a js function to ruby, using concurrent-ruby gem.

JS code:

async function test_js(redis) {
  const arrPromises = [];


  await Promise.all(arrPromisses);
  logger.info('remove success');

Ruby code:

promises = []

promises << Concurrent::Promise.new do
promises << Concurrent::Promise.new do

promises.each { |j| j.execute }
  then{|result| puts "remove success" }.
  rescue { |reason| puts reason }.execute

I'm quite confused cause Promise.all(arrPromisses) will execute all promisses in this array at the same time, while promises.each { |j| j.execute } delay a litle bit cause they're in loop.
Is there any better way to convert this js function to ruby code?
Thank you (bow)

Mikael Henriksson

I think that first of all you should prefer the Concurrent::Promises (plural) which seems to do the trick for me.

Let’s see if I can find the code...

@tuantv-0547 I did something like this:

def tasks
  files.map do |original_file|
    Concurrent::Promises.future(original_file) { |file| process_file(file) }.rescue do |exception|

def process_file(file)
  ProcessFile.perform(file: file, dir: dir, declaration_uuid: declaration_uuid)
If I am not mistaken this was kind of the whole point about the Promises api to provide better support for the exact thing you are trying to achieve.
Shawn Anderson
Not sure if this is the right place, but can anyone here describe the roadmap of getting this PR merged: ruby-concurrency/concurrent-ruby#856 ?
It's blocking my use of concurrent-ruby in production now (which makes me sad, because concurrent-ruby is awesome!)
Aditya C S
Noticed a strange behaviour. Channel.select doesn't block on channels and when used within loop it consumes full cpu(single core). Created an issue here ruby-concurrency/concurrent-ruby#883.

Hi guys!
I have read the doc about high level abstracts but I am still unable to find out what to use.
Here is my use case:

I have a sidekiq worker class that run for quite long sometimes.
Jobs and their states are persisted in database records.

class Worker
  include Sidekiq::Worker

  def perform



However since sometimes worker processes are restarted due to code release
The job record state is "stuck" on "started"
My idea is to raise error when sidekiq is detected to be "quiet" and rescue that error to update job status.
Can someone provide some advice/direction on the implementaion?

Tried Concurrent::TimerTask but my sample code would not raise error on main thread
timer_task = Concurrent::TimerTask.new(execution_interval: 1, run_now: false) do |task|
  task.execution_interval.to_i.times{ STDOUT.puts 'Boom! ' }
  STDOUT.print "\n"
  task.execution_interval += 1
  if task.execution_interval > 2
    STDOUT.puts 'Stopping...'
    raise RuntimeError.new("bye")
timer_task.with_observer do |_time, _result, ex|
  STDOUT.puts "in observer"
  next unless ex
  STDOUT.puts ex
  if ex.is_a?(RuntimeError)
    STDOUT.puts "ex is Interrupt"
    raise ex
main_thread = ::Thread.current
timer_task = Concurrent::TimerTask.new(execution_interval: 1, run_now: false) do |task|
  $sidekiq_is_quiet.tap do |quiet|
    task.shutdown if quiet
timer_task.with_observer do |_time, quiet|
  puts "with_observer >>"
  next unless quiet

  puts "raising"
  main_thread.raise "Sidekiq is quiet!"
Just got this and it seems working
Michael Kuklinski
Hi there!
I'm wondering if it's possible to pass an additional lock/mutex to something such as Concurrent::Array in order to more easily perform atomic tasks on multiple collections at once
such as where I need to remove something from one and add it to another, atomically
Michael Kuklinski
Also, is there a proper means by which to promote a ReadWriteLock in read-lock state to write-lock (and demote)?
Alex Maslakov
Why is it not found?
irb(main):001:0> require 'concurrent'
=> true

irb(main):002:0> puts "Main thread: #{Thread.current}"
Main thread: #<Thread:0x00005581cd29b428 run>
=> nil

irb(main):004:1* Concurrent::Channel.go do
irb(main):005:1*   puts "Goroutine thread: #{Thread.current}"
irb(main):006:0> end

Traceback (most recent call last):
        4: from /home/alex/.rubies/ruby-3.0.0/bin/irb:23:in `<main>'
        3: from /home/alex/.rubies/ruby-3.0.0/bin/irb:23:in `load'
        2: from /home/alex/.rubies/ruby-3.0.0/lib/ruby/gems/3.0.0/gems/irb-1.3.0/exe/irb:11:in `<top (required)>'
        1: from (irb):3:in `<main>'
NameError (uninitialized constant Concurrent::Channel)
Ben Sheldon (he/him)
If channels are still "edge" it needs to be required directly eg require "concurrent/channels"
Oops, that should be "concurrent/channel" (singular)
Andy Maleh

I'd hate to bother you, but I recently used 'concurrent-ruby' inside Glimmer and blogged about an example of taking advantage of it over here, leveraging thread pools: https://andymaleh.blogspot.com/2021/02/glimmer-dsl-for-swt-mandelbrot-fractal.html

Java 8 and later versions offer something even superior to thread pools called parallel streams (which build on thread pools behind the scenes as a higher abstraction), enabling my original loop implementation before parallelization (not shown in link) to work by changing a single keyword only (in Java, you switch stream() to parallelStream()) instead of instantiating a thread pool, distributing work, and waiting for it to finish.

What is the closet equivalent to Java parallel streams in "concurrent-ruby"?

Thanks and Godspeed.

Ben Sheldon (he/him)

@AndyObtiva that's cool! I think the closest equivalent is a Future: https://ruby-concurrency.github.io/concurrent-ruby/master/Concurrent/Future

A future will implicitly run on a global thread pool, but it's also possible to pass it an explicit thread pool too.