Subclassing Thread?

[Stephen Ware]

Is it possible to launch a Ruby thread without passing a block to
Thread.new?

Those familiar with threading in Java will know that you can write a
class that is a subclass of Thread, and then put the thread's code into
'public static void run,' which gets executed once thread.start is
called. Can something similar to this be done in Ruby?

Basically, I want to write a Ruby class that is subclass of thread, and
whose 'initialize' method is called when it is created. Can it be done?

Thanks,
Stephen

 

[yermej]

Is it possible to launch a Ruby thread without passing a block to
Thread.new?

Those familiar with threading in Java will know that you can write a
class that is a subclass of Thread, and then put the thread's code into
'public static void run,' which gets executed once thread.start is
called. Can something similar to this be done in Ruby?

Basically, I want to write a Ruby class that is subclass of thread, and
whose 'initialize' method is called when it is created. Can it be done?

Thanks,
Stephen

This seems to work:

class MyThread < Thread
def initialize
super("purple monkey dishwasher") {|str| puts "She said,
'#{str}.'"}
end
end

MyThread.new

She said, 'purple monkey dishwasher.'
=> #<MyThread:0x2aaaac528d40 run>

Adjust arguments to #initialize as needed.

Jeremy

 

[7stud --]

Those familiar with threading in Java will know that you can write a
class that is a subclass of Thread, and then put the thread's code into
'public static void run,' which gets executed once thread.start is
called. Can something similar to this be done in Ruby?

The following simulates calling run to start a thread. It stops the
thread as soon as it starts, and then restarts the thread when needed:

class MyThread < Thread
def initialize(x, y)
super(x, y) do |val1, val2|
Thread.stop
puts "In thread..."
puts val1, val2
puts
end
end
end

t = MyThread.new("hello", "world")
puts "main program"
puts
sleep(2)

t.run

t.join
sleep(2)
puts "main program ending..."

 

[Kero]

Those familiar with threading in Java will know that you can write a
The usual question is, why would you want that?
A Thread, by its nature, is something that should be running.
Especially delaying the start means... there's no underlying thread yet!

And I really love the syntax of Ruby:
Thread.new {
// thread's code
}

What are you missing?

 

[Stephen Ware]

The usual question is, why would you want that?
A Thread, by its nature, is something that should be running.
Especially delaying the start means... there's no underlying thread yet!

My motivation for wanting the thread in a separate class is simply
convenience. The class will be very large... several pages of code at
least... so putting it into a block would be a little unwieldy.

Thanks very much for your suggestions. I've found another method that
seems to work well also. Rather than subclassing Thread, I have written
the class (call it "User") as a normal class and done this:

Thread.new(args){|args| User.new(args)}

That seems to accomplish what I'm going for.

Thanks for your help!

 

[Ari Brown]

The usual question is, why would you want that?
A Thread, by its nature, is something that should be running.
Especially delaying the start means... there's no underlying thread
yet!

And I really love the syntax of Ruby:
Thread.new {
// thread's code
}

Quick thread question:

Does a thread need to be started with x.join, or will it start
automatically?

Ari
--------------------------------------------|
If you're not living on the edge,
then you're just wasting space.

 

[7stud --]

Quick thread question:

Does a thread need to be started with x.join, or will it start
automatically?

As this thread highlights, there doesn't seem to be a way to create a
thread in Ruby without starting it. So, the answer to your question
is: no, x.join does not start a thread. In fact, join() stops the
thread in which the join() statement appears.

 

[Robert Klemme]

My motivation for wanting the thread in a separate class is simply
convenience. The class will be very large... several pages of code at
least... so putting it into a block would be a little unwieldy.

Personally I always found the Java way to inherit java.lang.Thread
inferior to using Runnable because the latter is much more flexible.
So from my point of view you are asking for the worse alternative.

Btw, if your class is multiple screen pages this *may* be an
indication that you should do some refactoring and distribute
functionality across multiple classes.

Thanks very much for your suggestions. I've found another method that
seems to work well also. Rather than subclassing Thread, I have written
the class (call it "User") as a normal class and done this:

Thread.new(args){|args| User.new(args)}

That seems to accomplish what I'm going for.

That's also what I'd do.

Kind regards

robert