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?
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
--
Posted viahttp://www.ruby-forum.com/.
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
···
On Sep 30, 1:55 am, Stephen Ware <sgw...@gmail.com> wrote:
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)
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 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
}
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:
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.
···
On Sep 30, 2007, at 12:10 PM, Kero wrote:
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 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
}
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.
Kero wrote:
> 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.
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:
