Ruby: run irb from trap context?
The following example is given in the book Programming Ruby 1.9 & 2.0:
require 'irb'
trap "INT" do
IRB.start
end
count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
end
Unfortunately, if I run this code with my Ruby 2.5.1 setup I get the following ThreadError
(run_irb.rb is the name of the file with the code above):
24: from run_irb.rb:8:in `<main>'
23: from run_irb.rb:8:in `loop'
22: from run_irb.rb:12:in `block in <main>'
21: from run_irb.rb:12:in `sleep'
20: from run_irb.rb:4:in `block in <main>'
19: from /usr/lib/ruby/2.5.0/irb.rb:376:in `start'
18: from /usr/lib/ruby/2.5.0/irb/init.rb:17:in `setup'
17: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `init_config'
16: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `new'
15: from /usr/lib/ruby/2.5.0/irb/locale.rb:32:in `initialize'
14: from /usr/lib/ruby/2.5.0/irb/locale.rb:108:in `load'
13: from /usr/lib/ruby/2.5.0/irb/locale.rb:124:in `find'
12: from /usr/lib/ruby/2.5.0/irb/locale.rb:145:in `search_file'
11: from /usr/lib/ruby/2.5.0/irb/locale.rb:157:in `each_localized_path'
10: from /usr/lib/ruby/2.5.0/irb/locale.rb:167:in `each_sublocale'
9: from /usr/lib/ruby/2.5.0/irb/locale.rb:158:in `block in each_localized_path'
8: from /usr/lib/ruby/2.5.0/irb/locale.rb:150:in `block in search_file'
7: from /usr/lib/ruby/2.5.0/rubygems.rb:213:in `try_activate'
6: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find_by_path'
5: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find'
4: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `each'
3: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1064:in `block in find_by_path'
2: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:40:in `require'
1: from /usr/lib/ruby/2.5.0/monitor.rb:185:in `mon_enter'
/usr/lib/ruby/2.5.0/monitor.rb:185:in `lock': can't be called from trap context (ThreadError)
Is there a way to get the irb run from the trap context with Ruby 2.5.1?
ruby irb
add a comment |
The following example is given in the book Programming Ruby 1.9 & 2.0:
require 'irb'
trap "INT" do
IRB.start
end
count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
end
Unfortunately, if I run this code with my Ruby 2.5.1 setup I get the following ThreadError
(run_irb.rb is the name of the file with the code above):
24: from run_irb.rb:8:in `<main>'
23: from run_irb.rb:8:in `loop'
22: from run_irb.rb:12:in `block in <main>'
21: from run_irb.rb:12:in `sleep'
20: from run_irb.rb:4:in `block in <main>'
19: from /usr/lib/ruby/2.5.0/irb.rb:376:in `start'
18: from /usr/lib/ruby/2.5.0/irb/init.rb:17:in `setup'
17: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `init_config'
16: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `new'
15: from /usr/lib/ruby/2.5.0/irb/locale.rb:32:in `initialize'
14: from /usr/lib/ruby/2.5.0/irb/locale.rb:108:in `load'
13: from /usr/lib/ruby/2.5.0/irb/locale.rb:124:in `find'
12: from /usr/lib/ruby/2.5.0/irb/locale.rb:145:in `search_file'
11: from /usr/lib/ruby/2.5.0/irb/locale.rb:157:in `each_localized_path'
10: from /usr/lib/ruby/2.5.0/irb/locale.rb:167:in `each_sublocale'
9: from /usr/lib/ruby/2.5.0/irb/locale.rb:158:in `block in each_localized_path'
8: from /usr/lib/ruby/2.5.0/irb/locale.rb:150:in `block in search_file'
7: from /usr/lib/ruby/2.5.0/rubygems.rb:213:in `try_activate'
6: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find_by_path'
5: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find'
4: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `each'
3: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1064:in `block in find_by_path'
2: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:40:in `require'
1: from /usr/lib/ruby/2.5.0/monitor.rb:185:in `mon_enter'
/usr/lib/ruby/2.5.0/monitor.rb:185:in `lock': can't be called from trap context (ThreadError)
Is there a way to get the irb run from the trap context with Ruby 2.5.1?
ruby irb
I can understand why there is an error for this. What is the use-case?
– Max
Nov 20 '18 at 19:38
add a comment |
The following example is given in the book Programming Ruby 1.9 & 2.0:
require 'irb'
trap "INT" do
IRB.start
end
count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
end
Unfortunately, if I run this code with my Ruby 2.5.1 setup I get the following ThreadError
(run_irb.rb is the name of the file with the code above):
24: from run_irb.rb:8:in `<main>'
23: from run_irb.rb:8:in `loop'
22: from run_irb.rb:12:in `block in <main>'
21: from run_irb.rb:12:in `sleep'
20: from run_irb.rb:4:in `block in <main>'
19: from /usr/lib/ruby/2.5.0/irb.rb:376:in `start'
18: from /usr/lib/ruby/2.5.0/irb/init.rb:17:in `setup'
17: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `init_config'
16: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `new'
15: from /usr/lib/ruby/2.5.0/irb/locale.rb:32:in `initialize'
14: from /usr/lib/ruby/2.5.0/irb/locale.rb:108:in `load'
13: from /usr/lib/ruby/2.5.0/irb/locale.rb:124:in `find'
12: from /usr/lib/ruby/2.5.0/irb/locale.rb:145:in `search_file'
11: from /usr/lib/ruby/2.5.0/irb/locale.rb:157:in `each_localized_path'
10: from /usr/lib/ruby/2.5.0/irb/locale.rb:167:in `each_sublocale'
9: from /usr/lib/ruby/2.5.0/irb/locale.rb:158:in `block in each_localized_path'
8: from /usr/lib/ruby/2.5.0/irb/locale.rb:150:in `block in search_file'
7: from /usr/lib/ruby/2.5.0/rubygems.rb:213:in `try_activate'
6: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find_by_path'
5: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find'
4: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `each'
3: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1064:in `block in find_by_path'
2: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:40:in `require'
1: from /usr/lib/ruby/2.5.0/monitor.rb:185:in `mon_enter'
/usr/lib/ruby/2.5.0/monitor.rb:185:in `lock': can't be called from trap context (ThreadError)
Is there a way to get the irb run from the trap context with Ruby 2.5.1?
ruby irb
The following example is given in the book Programming Ruby 1.9 & 2.0:
require 'irb'
trap "INT" do
IRB.start
end
count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
end
Unfortunately, if I run this code with my Ruby 2.5.1 setup I get the following ThreadError
(run_irb.rb is the name of the file with the code above):
24: from run_irb.rb:8:in `<main>'
23: from run_irb.rb:8:in `loop'
22: from run_irb.rb:12:in `block in <main>'
21: from run_irb.rb:12:in `sleep'
20: from run_irb.rb:4:in `block in <main>'
19: from /usr/lib/ruby/2.5.0/irb.rb:376:in `start'
18: from /usr/lib/ruby/2.5.0/irb/init.rb:17:in `setup'
17: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `init_config'
16: from /usr/lib/ruby/2.5.0/irb/init.rb:112:in `new'
15: from /usr/lib/ruby/2.5.0/irb/locale.rb:32:in `initialize'
14: from /usr/lib/ruby/2.5.0/irb/locale.rb:108:in `load'
13: from /usr/lib/ruby/2.5.0/irb/locale.rb:124:in `find'
12: from /usr/lib/ruby/2.5.0/irb/locale.rb:145:in `search_file'
11: from /usr/lib/ruby/2.5.0/irb/locale.rb:157:in `each_localized_path'
10: from /usr/lib/ruby/2.5.0/irb/locale.rb:167:in `each_sublocale'
9: from /usr/lib/ruby/2.5.0/irb/locale.rb:158:in `block in each_localized_path'
8: from /usr/lib/ruby/2.5.0/irb/locale.rb:150:in `block in search_file'
7: from /usr/lib/ruby/2.5.0/rubygems.rb:213:in `try_activate'
6: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find_by_path'
5: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `find'
4: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1063:in `each'
3: from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1064:in `block in find_by_path'
2: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:40:in `require'
1: from /usr/lib/ruby/2.5.0/monitor.rb:185:in `mon_enter'
/usr/lib/ruby/2.5.0/monitor.rb:185:in `lock': can't be called from trap context (ThreadError)
Is there a way to get the irb run from the trap context with Ruby 2.5.1?
ruby irb
ruby irb
asked Nov 20 '18 at 19:14
Min-Soo PipefeetMin-Soo Pipefeet
20211
20211
I can understand why there is an error for this. What is the use-case?
– Max
Nov 20 '18 at 19:38
add a comment |
I can understand why there is an error for this. What is the use-case?
– Max
Nov 20 '18 at 19:38
I can understand why there is an error for this. What is the use-case?
– Max
Nov 20 '18 at 19:38
I can understand why there is an error for this. What is the use-case?
– Max
Nov 20 '18 at 19:38
add a comment |
1 Answer
1
active
oldest
votes
Ruby 2.0 does not allow Mutex#lock within a signal handler
According to this bug 7917 in ruby lang this is the "expected" behaviour. So you've basically found a language bug and a book bug because the author didn't test this example in ruby 2.0 (confirmed that it works in 1.9.)
An alternative method is to use an exception/rescue and execute an IRB
session from an interrupt like this:
require 'irb'
count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
rescue Interrupt => e
IRB.start
break
end
The above will correctly trap an interrupt and allow an IRB
session to start. I did notice that IRB.start
won't give you a local execution context, so you may want to look at binding.irb
that let's you start a more useful debugging session like this:
$ ruby thread-test.rb
1
2
^C
[1] irb(main)>
From: /work/_scratch/thread-test/thread-test.rb @ line 11 :
6: puts count
7: puts "Value = #{@value}" if defined? @value
8: sleep 1
9: rescue Interrupt => e
10: binding.irb
=> 11: break
12: end
[2] irb(main)> e
=> Interrupt
[3] irb(main)> count
=> 2
I found a few blog posts on handling Signals, Traps, and Rescues and Graceful Shutdown that may help you further with your problem.
2
Since Ruby 2.4 there'sbinding.irb
to get the local context. You don't need pry.
– Max
Nov 20 '18 at 19:35
@Max no way!?!? TIL!
– Gavin Miller
Nov 20 '18 at 19:36
Thx. Works great. But if I changebreak
toretry
ornext
I can only onceCtrl-C
to irb, the followingCtrl-C
s are ignored. Any idea why?
– Min-Soo Pipefeet
Nov 21 '18 at 6:18
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53399991%2fruby-run-irb-from-trap-context%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Ruby 2.0 does not allow Mutex#lock within a signal handler
According to this bug 7917 in ruby lang this is the "expected" behaviour. So you've basically found a language bug and a book bug because the author didn't test this example in ruby 2.0 (confirmed that it works in 1.9.)
An alternative method is to use an exception/rescue and execute an IRB
session from an interrupt like this:
require 'irb'
count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
rescue Interrupt => e
IRB.start
break
end
The above will correctly trap an interrupt and allow an IRB
session to start. I did notice that IRB.start
won't give you a local execution context, so you may want to look at binding.irb
that let's you start a more useful debugging session like this:
$ ruby thread-test.rb
1
2
^C
[1] irb(main)>
From: /work/_scratch/thread-test/thread-test.rb @ line 11 :
6: puts count
7: puts "Value = #{@value}" if defined? @value
8: sleep 1
9: rescue Interrupt => e
10: binding.irb
=> 11: break
12: end
[2] irb(main)> e
=> Interrupt
[3] irb(main)> count
=> 2
I found a few blog posts on handling Signals, Traps, and Rescues and Graceful Shutdown that may help you further with your problem.
2
Since Ruby 2.4 there'sbinding.irb
to get the local context. You don't need pry.
– Max
Nov 20 '18 at 19:35
@Max no way!?!? TIL!
– Gavin Miller
Nov 20 '18 at 19:36
Thx. Works great. But if I changebreak
toretry
ornext
I can only onceCtrl-C
to irb, the followingCtrl-C
s are ignored. Any idea why?
– Min-Soo Pipefeet
Nov 21 '18 at 6:18
add a comment |
Ruby 2.0 does not allow Mutex#lock within a signal handler
According to this bug 7917 in ruby lang this is the "expected" behaviour. So you've basically found a language bug and a book bug because the author didn't test this example in ruby 2.0 (confirmed that it works in 1.9.)
An alternative method is to use an exception/rescue and execute an IRB
session from an interrupt like this:
require 'irb'
count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
rescue Interrupt => e
IRB.start
break
end
The above will correctly trap an interrupt and allow an IRB
session to start. I did notice that IRB.start
won't give you a local execution context, so you may want to look at binding.irb
that let's you start a more useful debugging session like this:
$ ruby thread-test.rb
1
2
^C
[1] irb(main)>
From: /work/_scratch/thread-test/thread-test.rb @ line 11 :
6: puts count
7: puts "Value = #{@value}" if defined? @value
8: sleep 1
9: rescue Interrupt => e
10: binding.irb
=> 11: break
12: end
[2] irb(main)> e
=> Interrupt
[3] irb(main)> count
=> 2
I found a few blog posts on handling Signals, Traps, and Rescues and Graceful Shutdown that may help you further with your problem.
2
Since Ruby 2.4 there'sbinding.irb
to get the local context. You don't need pry.
– Max
Nov 20 '18 at 19:35
@Max no way!?!? TIL!
– Gavin Miller
Nov 20 '18 at 19:36
Thx. Works great. But if I changebreak
toretry
ornext
I can only onceCtrl-C
to irb, the followingCtrl-C
s are ignored. Any idea why?
– Min-Soo Pipefeet
Nov 21 '18 at 6:18
add a comment |
Ruby 2.0 does not allow Mutex#lock within a signal handler
According to this bug 7917 in ruby lang this is the "expected" behaviour. So you've basically found a language bug and a book bug because the author didn't test this example in ruby 2.0 (confirmed that it works in 1.9.)
An alternative method is to use an exception/rescue and execute an IRB
session from an interrupt like this:
require 'irb'
count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
rescue Interrupt => e
IRB.start
break
end
The above will correctly trap an interrupt and allow an IRB
session to start. I did notice that IRB.start
won't give you a local execution context, so you may want to look at binding.irb
that let's you start a more useful debugging session like this:
$ ruby thread-test.rb
1
2
^C
[1] irb(main)>
From: /work/_scratch/thread-test/thread-test.rb @ line 11 :
6: puts count
7: puts "Value = #{@value}" if defined? @value
8: sleep 1
9: rescue Interrupt => e
10: binding.irb
=> 11: break
12: end
[2] irb(main)> e
=> Interrupt
[3] irb(main)> count
=> 2
I found a few blog posts on handling Signals, Traps, and Rescues and Graceful Shutdown that may help you further with your problem.
Ruby 2.0 does not allow Mutex#lock within a signal handler
According to this bug 7917 in ruby lang this is the "expected" behaviour. So you've basically found a language bug and a book bug because the author didn't test this example in ruby 2.0 (confirmed that it works in 1.9.)
An alternative method is to use an exception/rescue and execute an IRB
session from an interrupt like this:
require 'irb'
count = 0
loop do
count += 1
puts count
puts "Value = #{@value}" if defined? @value
sleep 1
rescue Interrupt => e
IRB.start
break
end
The above will correctly trap an interrupt and allow an IRB
session to start. I did notice that IRB.start
won't give you a local execution context, so you may want to look at binding.irb
that let's you start a more useful debugging session like this:
$ ruby thread-test.rb
1
2
^C
[1] irb(main)>
From: /work/_scratch/thread-test/thread-test.rb @ line 11 :
6: puts count
7: puts "Value = #{@value}" if defined? @value
8: sleep 1
9: rescue Interrupt => e
10: binding.irb
=> 11: break
12: end
[2] irb(main)> e
=> Interrupt
[3] irb(main)> count
=> 2
I found a few blog posts on handling Signals, Traps, and Rescues and Graceful Shutdown that may help you further with your problem.
edited Nov 20 '18 at 19:41
answered Nov 20 '18 at 19:33
Gavin MillerGavin Miller
33.8k18106169
33.8k18106169
2
Since Ruby 2.4 there'sbinding.irb
to get the local context. You don't need pry.
– Max
Nov 20 '18 at 19:35
@Max no way!?!? TIL!
– Gavin Miller
Nov 20 '18 at 19:36
Thx. Works great. But if I changebreak
toretry
ornext
I can only onceCtrl-C
to irb, the followingCtrl-C
s are ignored. Any idea why?
– Min-Soo Pipefeet
Nov 21 '18 at 6:18
add a comment |
2
Since Ruby 2.4 there'sbinding.irb
to get the local context. You don't need pry.
– Max
Nov 20 '18 at 19:35
@Max no way!?!? TIL!
– Gavin Miller
Nov 20 '18 at 19:36
Thx. Works great. But if I changebreak
toretry
ornext
I can only onceCtrl-C
to irb, the followingCtrl-C
s are ignored. Any idea why?
– Min-Soo Pipefeet
Nov 21 '18 at 6:18
2
2
Since Ruby 2.4 there's
binding.irb
to get the local context. You don't need pry.– Max
Nov 20 '18 at 19:35
Since Ruby 2.4 there's
binding.irb
to get the local context. You don't need pry.– Max
Nov 20 '18 at 19:35
@Max no way!?!? TIL!
– Gavin Miller
Nov 20 '18 at 19:36
@Max no way!?!? TIL!
– Gavin Miller
Nov 20 '18 at 19:36
Thx. Works great. But if I change
break
to retry
or next
I can only once Ctrl-C
to irb, the following Ctrl-C
s are ignored. Any idea why?– Min-Soo Pipefeet
Nov 21 '18 at 6:18
Thx. Works great. But if I change
break
to retry
or next
I can only once Ctrl-C
to irb, the following Ctrl-C
s are ignored. Any idea why?– Min-Soo Pipefeet
Nov 21 '18 at 6:18
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53399991%2fruby-run-irb-from-trap-context%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I can understand why there is an error for this. What is the use-case?
– Max
Nov 20 '18 at 19:38