Hi guys,
this problem has been costing me some nerves now. I've tried various
things, including EventMachine, with no luck (maybe I did something
wrong).
Anyhow, I finally gave up trying a direct approach and tried a
sub-process/socket approach similar to what Ara suggested.
Here's something that finally works:
require 'socket'
require 'win32/process'
PORT_NUMBER = 12345
CHILD_PROC = 'ruby -e "' <<
'sleep 0.1;' <<
'csock = TCPSocket.new(\'localhost\',' << PORT_NUMBER.to_s <<
');' <<
'loop{a = gets; csock.print a; exit if a =~ /^exit$/;}'
p = Process.create(:app_name => CHILD_PROC)
#create a green thread that counts every second, to prove that the
parent process is not blocked
t = Thread.new{c = 0; loop{c+=1; puts c;sleep 1}}
l = TCPServer.new('localhost', PORT_NUMBER)
psock = l.accept and l.close
loop{ a = psock.gets; print "Got: #{a}"; exit if exit if a =~ /^exit$/;}
(Note: the example isn't very useful, all it's supposed to show is that
the ticker thread is still running while the loop in the parent thread
is blocking on the psock.gets).
I have to admit that I'm not very experienced with either windows
programming or network programming, so while this works I still have
some questions.
1. Both parent and child process run in the same console window. Who
"owns" stdin, stdout and stderr? Is there a way that the child process
could own stdin and the parent stdout and stderr?
2. Luis/Dan - you mentioned that Park Heesob has submitted a patch that
should actually fix the original problem in MRI, but that there were
some problems with it and therefore it had been reverted. Does anybody
know whether the latest patchlevel of 1.8.6 (p115 I think) does have the
problem fixed? If yes, can I download the patch in binary format (so far
I've been using the One-click-installer, I have no experience with
building ruby from source).
3. How does fxri circumvent this problem? I can start a ticker thread in
fxri and it's happily ticking away. If I try the same thing in irb in a
console, the ticker stalls until I type stuff.
Thanks,
Armin
···
--
Posted via http://www.ruby-forum.com/.