Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove AtExit code #841

Merged
merged 11 commits into from Feb 7, 2020
Merged

Conversation

fzakaria
Copy link
Contributor

@fzakaria fzakaria commented Jan 27, 2020

Following #840 which allowed all threads created by concurrent-ruby
to be marked as daemon -- specifically in JRuby; the "AtExit" handling
is no longer needed.

Delete all references to "AtExit" and replace it with clearer
documentation that the users can select whether the threads started
shall be marked as daemon threads.

This would be considered a breaking change since the API surface is being modified.
I don't expect consumers of concurrent-ruby however to have used it. The reliance on the :auto-terminate option continues to work.

Conceptually, relying on the fact that threads are marked as daemon is much simpler & maps closer to the ExecutorService API which the library seems to model itself after (or the Java concurrent libraries in general).

Information regarding what it means to mark a thread as daemon:

When a Java Virtual Machine starts up, there is usually a single non-daemon thread (which typically calls the method named main of some designated class).
The Java Virtual Machine continues to execute threads until either of the following occurs:

  1. The exit method of class Runtime has been called and the security manager has permitted the exit operation to take place.
  2. All threads that are not daemon threads have died, either by returning from the call to the run method or by throwing an exception that propagates beyond the run method.

Following ruby-concurrency#840 which allowed all threads created by concurrent-ruby
to be marked as daemon -- specifically in JRuby; the "AtExit" handling
is no longer needed.

Delete all references to "AtExit" and replace it with clearer
documentation that the users can select whether the threads started
shall be marked as daemon threads.

> When a Java Virtual Machine starts up, there is usually a single non-daemon thread (which typically calls the method named main of some designated class).
> The Java Virtual Machine continues to execute threads until either of the following occurs:
>
> 1. The exit method of class Runtime has been called and the security manager has permitted the exit operation to take place.
> 2. All threads that are not daemon threads have died, either by returning from the call to the run method or by throwing an exception that propagates beyond the run method.
Copy link
Member

@pitr-ch pitr-ch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for following up! I've added few related cleanups into the PR.

CHANGELOG.md Outdated Show resolved Hide resolved
pitr-ch and others added 4 commits February 3, 2020 09:53
- disable_at_exit_handlers! has to be kept as noop not to break current usages
- cleanup auto_terminate handling
- remove ns_auto_terminate attribute
- deprecate auto_terminate=
Add @LikeLakers2 suggestion.

Co-Authored-By: MichiRecRoom <1008889+LikeLakers2@users.noreply.github.com>
Fix grammatical error in configuration.rb
Fix grammatical error in configuration.rb
@fzakaria
Copy link
Contributor Author

fzakaria commented Feb 3, 2020

@pitr-ch looking the failures the builds are passing but not terminating.
Looks like one of the JRuby threads are not daemonizing.

@fzakaria
Copy link
Contributor Author

fzakaria commented Feb 3, 2020

Sweet the Travis CI build passed with my latest commit @pitr-ch

@fzakaria fzakaria requested a review from pitr-ch February 3, 2020 23:06
@@ -212,6 +212,8 @@ module Concurrent
pid = spawn RbConfig.ruby, test_file
Process.waitpid pid
expect($?.success?).to eq true
rescue Errno::ECHILD
# child already gone
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah! I was also fixing this :)

            rescue Errno::ECHILD
              # the child could quit out fast enough before we try to wait for it!

I think we could TODO move this test to executor_service_shared & have pool_quits start every type of executor service: cached & single executor

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah that sounds like a good idea! Would you be willing to do it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@fzakaria
Copy link
Contributor Author

fzakaria commented Feb 5, 2020

Failure does not seem related -- i re-triggered build with empty commit.

Failures:
  1) Concurrent::Map updates dont block reads
     Failure/Error: expect(joined_thread).not_to eq nil
     
       expected: value != nil
            got: nil
     
       (compared using ==)

...
     # ./spec/concurrent/map_spec.rb:268:in `block in Concurrent'

@pitr-ch
Copy link
Member

pitr-ch commented Feb 6, 2020

Thanks. I will remove the last commit and merge. (You can also trigger the build again by amending the last commit and force by force-pushing.)

@fzakaria
Copy link
Contributor Author

fzakaria commented Feb 6, 2020

Just squash merge it @pitr-ch ?

@pitr-ch
Copy link
Member

pitr-ch commented Feb 6, 2020

Yeah that works as well, I planned git reset --hard HEAD^; git push -f. I won't get to it until tomorrow though.

@fzakaria
Copy link
Contributor Author

fzakaria commented Feb 6, 2020

I just did that & it's using the previous failed check of that commit :(

@fzakaria
Copy link
Contributor Author

fzakaria commented Feb 6, 2020

Had to amend the HEAD commit anyways

@pitr-ch
Copy link
Member

pitr-ch commented Feb 7, 2020

Thanks for the PR Farid!

@pitr-ch pitr-ch merged commit 8ccb214 into ruby-concurrency:master Feb 7, 2020
@fzakaria
Copy link
Contributor Author

fzakaria commented Feb 7, 2020

thanks @pitr-ch
I'm enjoying working on this project.
Is there another issue you think worth looking at to help?

@pitr-ch
Copy link
Member

pitr-ch commented Feb 10, 2020

Awesome, thanks for the offer 👍 This project definitely needs more contributors! This #796 deserves some attention. Let me know if that interests you and I will assign it to you. If not please have a look at https://github.com/ruby-concurrency/concurrent-ruby/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Alooking-for-contributor

@fzakaria
Copy link
Contributor Author

@pitr-ch on it.

quartzmo added a commit to quartzmo/google-cloud-ruby that referenced this pull request Apr 22, 2020
quartzmo added a commit to googleapis/google-cloud-ruby that referenced this pull request Apr 22, 2020
* Add rubocop-minitest
* Run bundle exec rubocop --only Minitest/GlobalExpectations -a
* Revert rubocop-minitest
* Manually fix unit test errors
* Remove deprecated Concurrent.disable_at_exit_handlers! from acceptance test helper.rb since it now has no effect, see ruby-concurrency/concurrent-ruby#841

refs: #4110
refs: #4116
pr:  #5654
adamruzicka added a commit to adamruzicka/dynflow that referenced this pull request Jan 26, 2024
Concurrent: [DEPRECATED] Method #disable_at_exit_handlers! has no effect
since it is no longer needed,
see ruby-concurrency/concurrent-ruby#841
adamruzicka added a commit to adamruzicka/dynflow that referenced this pull request Jan 30, 2024
Concurrent: [DEPRECATED] Method #disable_at_exit_handlers! has no effect
since it is no longer needed,
see ruby-concurrency/concurrent-ruby#841
adamruzicka added a commit to adamruzicka/dynflow that referenced this pull request Jan 31, 2024
Concurrent: [DEPRECATED] Method #disable_at_exit_handlers! has no effect
since it is no longer needed,
see ruby-concurrency/concurrent-ruby#841
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants