[Win32utils-devel] win32-process 0.3.1 is out

win32utils-devel at rubyforge.org win32utils-devel at rubyforge.org
Fri Dec 10 15:54:56 EST 2004


On Fri, 10 Dec 2004 14:37:35 -0600, win32utils-devel at rubyforge.org
<win32utils-devel at rubyforge.org> wrote:
> Hi Aslak,
> 
> 
> 
> > -----Original Message-----
> > From: win32utils-devel-bounces at rubyforge.org
> > [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of
> > win32utils-devel at rubyforge.org
> > Sent: Friday, December 10, 2004 1:13 PM
> > To: win32utils-devel at rubyforge.org
> > Subject: Re: [Win32utils-devel] win32-process 0.3.1 is out
> >
> >
> > Thanks Dan, much appreciated.
> >
> > I have some other patches coming up soon :-) Here is what I'd
> > like to do (expressed as a unit test since I am a TDD
> > zealot). This relies on the soon-to-be popen4.
> >
> > require 'test/unit'
> > require 'timeout'
> > require "win32/open3"
> > require 'win32/process'
> >
> > class Process2Test < Test::Unit::TestCase
> >   def test_can_timeout_native_function
> >     timeout(2) do
> >       pid = nil
> >       begin
> >         Open4.popen4("notepad") do |stdin, stdout, stderr, pid|
> >           Process.waitpid2(pid)
> >         end
> >         fail("Should have timed out")
> >       rescue Timeout::Error => expected
> >         Process.kill(-9, pid) if pid
> >       end
> >     end
> >   end
> > end
> >
> > The problem is - the timeout never happens and the test
> > program blocks until notepad is closed manually.
> >
> > Any idea how to implement this so that the timeout can
> > happen? I am assuming the problem is related to the blocking
> > nature of WaitForSingleObject, and that we can't interrupt
> > it. Do we have to introduce some threads and mutexes and and
> > such from the win32 api to deal with this?
> >
> > Cheers,
> > Aslak
> 
> As is, I don't think that code can work on Win32.  The only answer I can
> think of would be to allow a timeout value as the second argument to the
> waitpid and waitpid2 methods.  So, instead of having INFINITE hard coded
> as the second argument to WaitForSingleObject, for example, you could do
> Process.waitpid2(pid,2), and the 2 (x1000, since the 2nd arg is
> milliseconds) would be passed as the 2nd argument to the
> WaitForSingleObject() function internally.
> 
> That seems a reasonable compromise to me, though I worry about breaking
> too much with the way things work on *nix.  Thoughts?
> 

The standard Ruby Process.waitpid2 method already takes a 2nd
argument, but this is a flag and not a timeout value. I think it would
be a bad idea to introduce incompatible semantics for the sake of
portability of ruby code beween windows and *nix.

I am pretty unfamiliar with the Win32 API, but I would assume it's
possible to use threads and mutexes in the C code.

Could the C code launch a new thread and do the WaitForSingleObject
there? Then the process_waitpid2 could block until a condition
variable is released - either as the result of WaitForSingleObject
returning, or as the result of a C-intercepted Ruby exception (the
timeout exception). I don't know if this is possible though - what do
you think - you're the Ruby-Win32-C specialist ;-)

Aslak

> - Dan
> 
> 
> 
> 
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>


More information about the win32utils-devel mailing list