win32utils devel - Dec 2004 - win32-process 0.3.1 is out

Hi all,

Just wanted to let you know that I released 0.3.1 last night.  This
addresses Bug #712 and incorporates Patches #1087 and #1137 (thanks
Aslak).

I''ll try to get an open4 implementation out this weekend, though I
noticed that Aslak''s patch is different than what Park originally had,
so I''ll have to decide which I prefer, or if they can be blended
somehow.

Regards,

Dan

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

On Fri, 10 Dec 2004 08:29:10 -0600, win32utils-devel@rubyforge.org
<win32utils-devel@rubyforge.org> wrote:
> Hi all,
> 
> Just wanted to let you know that I released 0.3.1 last night.  This
> addresses Bug #712 and incorporates Patches #1087 and #1137 (thanks
> Aslak).
> 
> I''ll try to get an open4 implementation out this weekend, though I
> noticed that Aslak''s patch is different than what Park originally
had,
> so I''ll have to decide which I prefer, or if they can be blended
> somehow.
> 
> Regards,
> 
> Dan
> 
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel@rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>

Hi Aslak,
> -----Original Message-----
> From: win32utils-devel-bounces@rubyforge.org 
> [mailto:win32utils-devel-bounces@rubyforge.org] On Behalf Of 
> win32utils-devel@rubyforge.org
> Sent: Friday, December 10, 2004 1:13 PM
> To: win32utils-devel@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?

- Dan

<snip>

Also, if anyone has any ideas as to how WUNTRACED or WNOHANG should work
on Win32 (if at all), I''m all ears. :)

- Dan

On Fri, 10 Dec 2004 14:37:35 -0600, win32utils-devel@rubyforge.org
<win32utils-devel@rubyforge.org> wrote:
> Hi Aslak,
> 
> 
> 
> > -----Original Message-----
> > From: win32utils-devel-bounces@rubyforge.org
> > [mailto:win32utils-devel-bounces@rubyforge.org] On Behalf Of
> > win32utils-devel@rubyforge.org
> > Sent: Friday, December 10, 2004 1:13 PM
> > To: win32utils-devel@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@rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>

<snip>
> > 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.
Heh - the 2nd argument is unused internally at the moment.  I put it
there in case we ever came up with definitions for WNOHANG and WUNTRACED
(or our own special constants).  Perhaps a 3rd argument?
> 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
Now there''s an idea.  I''ll have to look into it.  In the
meantime if you
or anyone else listening has any ideas as to what the actual C code
should be (Park?), I''d be happy to hear them. :)

- Dan