Ruby Threads in Windows

ruby-talk
1

Hi all. And thankyou in advance to anyone who responds.

I am quite new to Ruby and am working on Windows.

I need to spawn new threads in ruby on windows which I can do fine, and
I can see them in the windows process list. Is there are way of getting
the process ID back for a thread?

I can not use the Process module as my threads need to run concurrently
(and everythign I have read says I should be using threads) and every
time I try the "fork" command I am told its not supported.

I also looked at the windows-pr gem but so far no luck.

If I can get the ID of the process that the thread is running in I can
kill it by spawning a kill.exe command, but I have been unable to get
the process ID.

I can not kill the process by name as the name is shared by other
threads.

Thanks

Dave

···

--
Posted via http://www.ruby-forum.com/.

2

Oh yes, and the new threads are running exe's e.g.

Thread.new { system("myExe") }

···

--
Posted via http://www.ruby-forum.com/.

3

Hi all. And thankyou in advance to anyone who responds.

I am quite new to Ruby and am working on Windows.

I need to spawn new threads in ruby on windows which I can do fine, and
I can see them in the windows process list. Is there are way of getting
the process ID back for a thread?

It will be the same as the process id for the whole program. Threads
are done within the process.

I can not use the Process module as my threads need to run concurrently
(and everythign I have read says I should be using threads) and every
time I try the "fork" command I am told its not supported.

It's not on Windows. What are you trying to do (with the threads)?
You might find that DRb is better and kicking off several ruby programs
that connect to your DRb Server is what you want, if you have enough
processors>cores available.

I also looked at the windows-pr gem but so far no luck.

If I can get the ID of the process that the thread is running in I can
kill it by spawning a kill.exe command, but I have been unable to get
the process ID.

You will kill the whole program. Thread#kill already exists.

  x = Thread.new do
        compute_ultimate_question
      end
  vogon = Thread.new do
           Thread::kill(x)
          end

I can not kill the process by name as the name is shared by other
threads.

Thanks

Dave

        Hugh

···

On Tue, 4 Nov 2008, Dave Wilson wrote:

4

Threads don't spawn as separate processes in Ruby < 1.9 (I'm not positive
about >=1.9) You are actually creating a new process with the system
command. If you are just trying to avoid blocking you could use
system("start process") as start returns immediately. Otherwise I'm not
sure, you might have to spawn via Win32API rather than system to get the
pid.

···

On Mon, Nov 3, 2008 at 9:34 AM, Dave Wilson <davywilson@hotmail.com> wrote:

Oh yes, and the new threads are running exe's e.g.

Thread.new { system("myExe") }

--
Posted via http://www.ruby-forum.com/\.

--
"Hey brother Christian with your high and mighty errand, Your actions speak
so loud, I can't hear a word you're saying."

-Greg Graffin (Bad Religion)

5

Thanks for the quick responses guys.

Its late in the day here so I will read over them tomorrow and get back
to you.

My main issue is that the threads my app (and its a testing app) spawns
have the same name as the original running app. Long story short I dont
have much control over the environment, but recently I have been looking
to move to runit to try and clean the tests up, but what I have found is
originally the app ran as a ruby process from the command line (process
name was 'ruby'), spawning 'rubyw' processes. Now becuase eclypse runs
runit tests as a rubyw process (test and spawned threads now have same
process name), the code which killed off the old child processes is
acually killing the test itself.

As I said, I dont have full control over the environment (financial
company who are strict about OS types and approved technologies) so I am
somewhat limited in my options (win 2k is a nightmare).

So if anyone knows a better way to launch a new thread which I can
kill/terminate so it no longer appears in the process list, I am all
ears.

Thanks, and as I said I have not ahd a chance to review the responses.

···

--
Posted via http://www.ruby-forum.com/.

6

Thanks for the quick responses guys.

Its late in the day here so I will read over them tomorrow and get back
to you.

My main issue is that the threads my app (and its a testing app) spawns
have the same name as the original running app. Long story short I dont
have much control over the environment, but recently I have been looking
to move to runit to try and clean the tests up, but what I have found is
originally the app ran as a ruby process from the command line (process
name was 'ruby'), spawning 'rubyw' processes. Now becuase eclypse runs
runit tests as a rubyw process (test and spawned threads now have same
process name), the code which killed off the old child processes is
acually killing the test itself.

I'd still advise a step further back. What are you trying to achieve
that means you have multiple threads or processes, or jobs, or .....?

And, why do you have to kill them? Why can't they be allowed to complete?

If you must kill them based on time, use Timeout.rb .

As I said, I dont have full control over the environment (financial
company who are strict about OS types and approved technologies) so I am
somewhat limited in my options (win 2k is a nightmare).

Will they let you use Windows Powershell instead? Given that it's native
you may find it easier than trying to get Ruby to do what you want.
I can't remember if Win2k has CMD.exe and how sophisticted it is if it does.

So if anyone knows a better way to launch a new thread which I can
kill/terminate so it no longer appears in the process list, I am all
ears.

You've not really said what the problem you are trying to solve with this
is. If the jobs are ruby programs, then they might stay strictly within
threads in the same process.

Thanks, and as I said I have not ahd a chance to review the responses.

        Hugh

···

On Tue, 4 Nov 2008, Dave Wilson wrote:

7

OK thanks, I have solved the issue.

The original problem is to do with watir popup handling. My work has
written a massive (and bloated) testing framework around watir to test a
highly varient application. I am currently reworking this framework to
try and clean it up a but. The recommended approach for handling popups
in Watir does not seem to work on our machines (none of the unit tests
wupplied with watir work) and I currently cant upgrade them, so the
original test framework handled them by running ruby code in a new
process which ran in the background and waited for the popups.

The approach was

1) Launch new popup thread
2) Fire event that caused popup

In some cases we dont get popups (environment logins etc) so the rubyw
processes would remain until a new test would launch another popup
thread and then we would ahve 2 threads attempting to login at the same
time.

I hasten to add I did NOT design the original framework and I dont like
this brute force approach to popups. So taking your advice I have taken
a new approach which is to wrap the event that (potentially) causes the
popup in a timeout, and the recover to that timeout is a popup handler
which runs in the same thread. If the popup does not apprear, the
method does not time out so the popup handler is not created.

Its not a great solution but will do until the framework is updated to
the latest version of watir and ruby. And hopefully a newer OS.

Thanks for your help.

···

--
Posted via http://www.ruby-forum.com/.