Hi Ara,

I agree that the *principal* of the idea is about the only one to pursue 
on Windows.  I tried the following code:

def timeout seconds, key, &block
 pid = Process.pid
 signaler = IO.popen "ruby -e'sleep #{ seconds }; 
Process.kill(:#{key}.to_s, #{ pid }) rescue nil'"
 handler = Signal.trap(key){ raise 'timed out...' }
 begin
  block.call
 ensure
  Process.kill key, signaler.pid rescue nil
  Signal.trap(key, handler)
 end
end

Signal.list.keys.each do |key|
 puts key
 unless key == 'KILL'
  timeout(2, key) { p 'works' }
  timeout(1, key) { sleep 2; p 'does not work' }
 end
end

and it produced the following output:

>ruby timeout_test.rb
TERM
"works"
"does not work"
SEGV
"works"
"does not work"
KILL
EXIT
"works"
"does not work"
INT
"works"
"does not work"
FPE
"works"
"does not work"
ABRT
"works"
"does not work"
ILL
"works"
"does not work"
>Exit code: 0

--
Thanks!
Bryan

Ara Howard wrote:
> did you try the 'INT' signal?  there are only a few signals supports
> in windows between process and i forget which is which.  in any case,
> even if that exact code will not work the *principle* will: that of
> setting up an external process to do something to your (potentially
> blocked) process.  in fact it's the only way out when you consider
> ruby's thread impl.
>
-- 
Posted via http://www.ruby-forum.com/.