Project

General

Profile

Actions

Bug #4284

closed

Timeout.timeout may cause application exit unintetionally, again

Added by kosaki (Motohiro KOSAKI) over 13 years ago. Updated almost 13 years ago.

Status:
Closed
Target version:
ruby -v:
ruby 1.9.3dev (2010-12-22 trunk 30291) [x86_64-linux]
Backport:
[ruby-dev:43050]

Description

=begin
This issue was discovered during [Bug#4266] discussion.
Current timeout is racy.

Now, timeout module has following code.

def timeout()
begin
x = Thread.current
y = Thread.start {
begin
sleep sec
rescue => e
x.raise e
else
x.raise exception, "execution expired" if x.alive?
end
}
return yield(sec)
rescue exception => e
raise Error, e.message, e.backtrace
ensure
if y and y.alive?
y.kill
y.join # make sure y is dead.
end
end
end

Unfortunatelly,

y = Thread.start {}

is not an atomic operation. Then, A following race can occur.

CPU0(thread x) CPU1(thread y) remark

enter begin block
[thread construct] but no assign y yet
sleep sec
wakeup from sleep
x.raise
if y return false. (see above)

Therefore, CPU0 don't call y.join and leak y's thread resource. C# have solved
this two-step-construction vs asynchrounous exception race by RAII.

But unfortunately, Ruby don't have such language feature. So, We can't write
async-exception-safe code. One of solution is to move timeout module from ruby code
into c code as JRuby does. But I don't think timeout is only asynchrounos exception user.
we also have Interrupt class (for Ctrl-C) and I think we need to allow to write async
exception safe code by ruby.

Or, Am I missing something?
=end

Actions #1

Updated by kosaki (Motohiro KOSAKI) over 13 years ago

  • Status changed from Open to Closed

=begin
ruby-dev is no good place for this discussion. So, I'll close this ticket and reopen at ruby-core.

I'm sorry.
=end

Actions

Also available in: Atom PDF

Like0
Like0