From: Taisuke Yamada <tyamadajp@...>
Date: 2006-04-03T21:33:46+09:00
Subject: Correct way to close IO.popen pipe under Windows? (mingw)

Hi.

I'm currently writing a wxRuby program to visualize wireless
network (802.11), and is somewhat stuck with IO.popen behavior
under Windows.

My software is composed of two parts: one for gathering Wi-Fi
information through Windows NDIS/WMI API (CLI program written in C),
and the other for controlling the former and visualizing
collected result using Ruby/wxWindows. Gathered information is
passed over IO.popen pipe.

The problem is that whenever I try to close this pipe,
it never comes back. After some investigation, I found out
IO.close on Windows waits forever until invoked process exits.
Actually, this is same on UNIX (pclose(2) behavior), but it
was not a issue on UNIX as process gets interrupted by EPIPE.

So the question is: How can I run forever-looping CLI program
interactively on Windows? What I want to do is essentially as
follows:

  # double click event handler
  # - this must not block as it kills GUI interactiveness
  def on_mouse_double_click(event)
    IO.popen(cmd) do |io|
      while ! io.eof? do
        # update progress and check for user-requested cancellation
        if (user_req = update_progress_bar()) == CANCEL
          break
        end

        # stop processing once enough data is collected
        if got_enough_data(io.gets)
          break
        end
      end
    end
  end

As I wrote above, this event handler code blocks after it "broke"
out of the loop because implicit IO.close never returns.

For now, I worked around the problem by modifying invoked command
to exit if certain file exists, and updated above code to create
such file once break condition is met. But since this workaround
requires access to the source, I'd like to know cleaner way to do
the same thing, without any kind of kludge.

I also tried doing "kill(SIGKILL, io.pid)" before exiting the loop,
but it resulted to general unstability of the program as killed
process left environment in uncertain state. Other signals (SIGINT, etc)
had no effect on Windows.

Any ideas? Thanks in advance.
--
Taisuke Yamada, <tyamadajp@list.rakugaki.org>