ruby-concurrency / ruby-concurrency/concurrent-ruby

why use wait_for_termination method will stuck the code

Open
#1,004 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Ruby
Stars
5.8k
Forks
420
Avg merge
20h 45m
Merged PRs (30d)
4

Description

        user_ids,org,delete_restore = get_org_and_user(delete_restore_id)
        return unless user_ids.present?
        work_num = [user_ids.length,50].min
        thread_pool = Concurrent::FixedThreadPool.new(work_num)
        error_map = Concurrent::Map.new
        redis_key = RedisClient::DDRS_BULK_DELETE_KEY % org.id  ## TODO
        set_redis_total_num(redis_key,user_ids.length)
  
        user_ids.each do |id|
          thread_pool.post do
            #delete_single_user(id,error_map,redis_key)
            target_class = ClassFactory.create_dynamic_model("zendmodo", "privacy_settings", true)
            puts id
            puts target_class
          end
        end

       thread_pool.shutdown
       thread_pool.wait_for_termination

the wait_for_termination method will stuck the following code

target_class = ClassFactory.create_dynamic_model("zendmodo", "privacy_settings", true)
  • Operating system: linux
  • Ruby implementation: Ruby
  • concurrent-ruby version: 1.2.0
  • concurrent-ruby-ext installed: no
  • concurrent-ruby-edge used: no

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the thread_pool.shutdown and thread_pool.wait_for_termination calls in the issue's example, then investigate the worker's ClassFactory.create_dynamic_model call under Ruby with concurrent-ruby 1.2.0 and no concurrent-ruby-ext. Reproduce the hang on Linux and establish why the worker does not finish; done means the supplied workload terminates without leaving wait_for_termination stuck.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby
Domain
distributed-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.