Hello,
I've been googling last 2 days and still can't solve simple problem -
send signal to windows process (to be more specific - to another RUBY
script running as a new process). I can kill it (Process.kill 9, pid)
but I need to trap signal to save work progress so signal 9 (kill) can't
be used. But other signals are ignored (?).
Here some quick test case:
test.rb=
run = 1
trap(9) { run = -9 }
trap(4) { run = -4 }
trap(2) { run = -2 }
trap(15) { run = -15 }
loop do
print "#{Time.now.to_i}\r"
sleep 1
break if run < 0
end
puts "Result: #{run}"
I can confirm that this works on Linux. Perhaps your test2.rb exits
before test.rb starts. Try increasing the sleep time in test.rb to 5
seconds. That should be plenty, and if you get the same result as
before, perhaps there's a problem with this on Windows!
Have you tried using symbols rather than numeric equivalents i.e.: {{
Process.kill :INT, pid }} rather than {{ Process.kill 2, pid }}. I'm
not sure this will work since your hash for available signals includes
the correct values. But I'd try it anyway.
If all this fails, hope someone more knowledgeable about Ruby
implementation on Windows will reply, and perhaps even fix the problem.
Miroslav, I asked around (as I'm completely unknowledgeable about
windows process handling) -- I suspected it is much different than on
*nix, which is what the Process class is written for, and it is. They
gave me some google search terms you can try: "windows message pump"
···
On Sun, Apr 14, 2013 at 9:38 AM, Miroslav S. <lists@ruby-forum.com> wrote:
I've been googling last 2 days and still can't solve simple problem -
send signal to windows process (to be more specific - to another RUBY
script running as a new process). I can kill it (Process.kill 9, pid)
but I need to trap signal to save work progress so signal 9 (kill) can't
be used. But other signals are ignored (?).
..eh. Thanks for your advices (:INT = 2 = same result and googling
"windows message pump" gave me no helpful results. It's looks like there
is no way to send CTRL+C to windows process), I give up I'll just
create in every script small socket server, so instead of storing PIDs,
I'll store port numbers. Maybe ugly but it will work for sure..
Thanks, but like I said - I give up Don't have energy and time (and
experience with RUBY) for more googling to decide, what is best approach
for me.... I just need to pass 1 message (result) from child scripts and
from time to time tell them to stop. So I need simple bi-directional
communication.
I can process child's STDOUT to get results so only thing left is some
"IPC" for forced STOP. Sending INT signal was best for me because trap
in child scripts was already implemented but Window beat me.. So,
sockets looks like best solution - they are simple and cross-platform
with constant behavior (named pipes behave differently on win).
Try increasing the sleep time in test.rb to 5
seconds. That should be plenty, and if you get the same result as
before, perhaps there's a problem with this on Windows!
No, this is fine. Sleep 5 didn't change anything (I can see the counter
from test.rb even with sleep 1)
PS: Perhaps you should try forking your test2 if spawn does not work.
Fork is not implemented for Windows I tried use backticks but same
result.
But I suggest using threads instead if at all possible!
I have many stand-alone scripts and their count is incrementing, so I
can't use threads. I tried this on Windows 2008 server with same result
(dev PC is running Win7 64b)
If this doesn't work, I'll put in every script small TCPSocket listener
and tell them to stop
In your shoes I'd be starting with a search on "windows interprocess communication". It'll give a hint as to what is possible, and one of the approaches mentioned might be of interest to you.
Cheers,
Garth
···
On 15/04/13 15:48, Miroslav S. wrote:
..eh. Thanks for your advices (:INT = 2 = same result and googling
"windows message pump" gave me no helpful results. It's looks like there
is no way to send CTRL+C to windows process), I give up I'll just
create in every script small socket server, so instead of storing PIDs,
I'll store port numbers. Maybe ugly but it will work for sure..
I'll just
Don't have energy and time (and
I tried use backticks but same
I'll just