On Aug 12, 2008, at 12:38 PM, Bryan Richardson wrote:
def timeout(sec, pid)
begin
watchdog = IO.popen "ruby -e 'sleep(#{sec});
Process.kill(:KILL.to_s, #{pid}) rescue nil'"
yield
ensure
Process.kill('KILL', watchdog.pid) rescue nil
end
end
and I could call it like this:
@sim = WIN32OLE.new 'PwrWorld.SimulatorAuto'
...
begin
timeout(20, @sim.ProcessID) do @sim.RunScriptCommand('SolvePrimalLP()')
end
rescue WIN32OLERuntimeError
# rescue myself from the external application hanging up... i.e.
reinitialize @sim
end
However, it seems as though when creating the watchdog in the timeout
method IO.popen sometimes blocks execution. I can't tell if it's due
to the external (OLE) application blocking or something else. If I
don't use the timeout method the OLE application blocks at a different
time in the simulation, so I'm thinking it's not due to the OLE
application blocking...
--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama
what about starting another thread to monitor my results variable... i
still don't fully understand the scope of variables when a thread is
started.
···
--
bryan
Bryan Richardson wrote:
hi adam,
i don't test a property because the ole interface is not asynchronous.
my code looks like this -
do stuff...
result = @sim.RunScriptCommand('SolvePrimalLP()')
do stuff...
when the ole application hangs i never get to the second 'do stuff...'
--
bryan
Adam Shelly wrote:
How exactly do you wait for results? Do you test some property?
Can't you use that test as your loop sentinel?
`break if !monty.Results.empty?` or something like that...
i don't test a property because the ole interface is not asynchronous. my code looks like this -
do stuff...
result = @sim.RunScriptCommand('SolvePrimalLP()')
do stuff...
when the ole application hangs i never get to the second 'do stuff...'
I don't know much about ole... is RunScriptCommand blocking on a tcp socket call? If so, it should be possible to wrap a timeout block around RunScriptCommand. The timeout block starts another thread. If the timeout fires, the blocked call will be interrupted (ruby's thread scheduler works well if threads are blocked on socket ops, but not arbitrary C functions). You can rescue and clean up the socket.
···
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
At this point I can't say I've proven it... about the only thing I've
done is stick logging commands around the creation of the watchdog.
The log statement before gets logged, the one after does not.
However, I'm not exactly sure how log4r works either so who knows if
the OLE stuff is jacking with it also!
···
On Tue, Aug 12, 2008 at 1:37 PM, ara.t.howard <ara.t.howard@gmail.com> wrote:
On Aug 12, 2008, at 12:38 PM, Bryan Richardson wrote:
def timeout(sec, pid)
begin
watchdog = IO.popen "ruby -e 'sleep(#{sec});
Process.kill(:KILL.to_s, #{pid}) rescue nil'"
yield
ensure
Process.kill('KILL', watchdog.pid) rescue nil
end
end
and I could call it like this:
@sim = WIN32OLE.new 'PwrWorld.SimulatorAuto'
...
begin
timeout(20, @sim.ProcessID) do @sim.RunScriptCommand('SolvePrimalLP()')
end
rescue WIN32OLERuntimeError
# rescue myself from the external application hanging up... i.e.
reinitialize @sim
end
However, it seems as though when creating the watchdog in the timeout
method IO.popen sometimes blocks execution. I can't tell if it's due
to the external (OLE) application blocking or something else. If I
don't use the timeout method the OLE application blocks at a different
time in the simulation, so I'm thinking it's not due to the OLE
application blocking...
can you prove that it's popen blocking? seems very strange...
a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
h.h. the 14th dalai lama
However, it seems as though when creating the watchdog in the timeout
method IO.popen sometimes blocks execution. I can't tell if it's due
to the external (OLE) application blocking or something else. If I
don't use the timeout method the OLE application blocks at a different
time in the simulation, so I'm thinking it's not due to the OLE
application blocking...
can you prove that it's popen blocking? seems very strange...
I'm just jumping into the middle of the thread, so apologies if
I've missed something; but ...
popen blocks ALL ruby threads on windows. This has been the bane
of my existence for the past eight years.
The problem is due to Microsoft's venerable design strategy: You are
lost in a twisty little maze of API's, all incompatible.
On Windows, the "file handle" returned by popen is not a "socket",
and therefore is incompatible with "select".
/me raises a cup of hemlock in toast to Redmond
Note: Now that 1.9 ruby uses native threads, it should be possible
to implement a nonblocking popen. However, last time I tested 1.9
for this behavior, it still blocked. (This was several months ago.)
Regards,
Bill
···
From: "ara.t.howard" <ara.t.howard@gmail.com>
On Aug 12, 2008, at 12:38 PM, Bryan Richardson wrote:
RunScriptCommand is a OLE/COM call, so it's not going over TCP. I would
say it's definately a lower-level C call.
···
--
Bryan
Joel VanderWerf wrote:
I don't know much about ole... is RunScriptCommand blocking on a tcp
socket call? If so, it should be possible to wrap a timeout block around
RunScriptCommand. The timeout block starts another thread. If the
timeout fires, the blocked call will be interrupted (ruby's thread
scheduler works well if threads are blocked on socket ops, but not
arbitrary C functions). You can rescue and clean up the socket.
I CAN'T CATCH A BREAK ANYWHERE!!!! Argh... this is why I don't
develop on Windows!
···
On Tue, Aug 12, 2008 at 3:07 PM, Bill Kelly <billk@cts.com> wrote:
I'm just jumping into the middle of the thread, so apologies if
I've missed something; but ...
popen blocks ALL ruby threads on windows. This has been the bane
of my existence for the past eight years.
The problem is due to Microsoft's venerable design strategy: You are
lost in a twisty little maze of API's, all incompatible.
On Windows, the "file handle" returned by popen is not a "socket",
and therefore is incompatible with "select".
/me raises a cup of hemlock in toast to Redmond
Note: Now that 1.9 ruby uses native threads, it should be possible
to implement a nonblocking popen. However, last time I tested 1.9
for this behavior, it still blocked. (This was several months ago.)
