[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

ruby threads? the point?

Eric Armstrong

7/28/2006 4:47:00 PM

Saw an archived message yesterday that
said, "when one thread blocks, they all
block".

That matches my experience. I had a timer
thread and an interactive-controller
thread. But no display updates occur
in the timer thread until the user takes
an action in the controller thread.

What is the point of the having "threads"
if they don't allow to use the time that
would otherwise be spent waiting?

Game programs, interactive timers like
the one I was working on, and virtually
any program that really /needs/ threads
requires non-blocking behavior.

On *nix, I can fork a subsidiary process,
and that gives me sufficient control for
a timer app. But on windows, the fork call
says it is "not implemented".

So what is a windows app supposed to do?
29 Answers

Justin Collins

7/28/2006 4:59:00 PM

0

Eric Armstrong wrote:
> Saw an archived message yesterday that
> said, "when one thread blocks, they all
> block".
>
> That matches my experience. I had a timer
> thread and an interactive-controller
> thread. But no display updates occur
> in the timer thread until the user takes
> an action in the controller thread.
>
> What is the point of the having "threads"
> if they don't allow to use the time that
> would otherwise be spent waiting?
>
> Game programs, interactive timers like
> the one I was working on, and virtually
> any program that really /needs/ threads
> requires non-blocking behavior.
>
> On *nix, I can fork a subsidiary process,
> and that gives me sufficient control for
> a timer app. But on windows, the fork call
> says it is "not implemented".
>
> So what is a windows app supposed to do?
>

This hasn't been my experience at all. Do you have a simple example that
shows this behavior?
I have a program which involves quite a few threads, some waiting on
(multiple) user input, and it works as I would expect (when waiting on
input, it does other stuff). I even have a Timer object that works as
expected. I also use some threads just to get asynchronous function call
behavior.

So I'm a bit confused about your message :)

-Justin

Eric Armstrong

7/28/2006 9:19:00 PM

0

Justin Collins wrote:
> Eric Armstrong wrote:
>> Saw an archived message yesterday that
>> said, "when one thread blocks, they all
>> block".
>>
>
> This hasn't been my experience at all.
>
Yay! I'd rather be wrong!

> Do you have a simple example that
> shows this behavior?
>
Below. And now that I'm at work, rather than
at home, I've been able to determine that it
works as expected on my Solaris box, but fails
on Windows XP. (There, the display only updates
after pressing spacebar or some other key.)

Perhaps the problem is Curses on Windows??

---------------------------------
#!/usr/bin/env ruby

require 'curses'
include Curses

addstr "Press spacebar to start, x to exit: "
refresh

timer_thread = Thread.new do
100.downto(1) do |i|
addstr(".." + i.to_s)
refresh
sleep 1
end
end

begin
while true
c = getch
case c
when 32 # Space
#timer_thread.run

when ?x, ?X
exit
end
end
ensure
Thread.kill(timer_thread)
end

Justin Collins

7/28/2006 9:37:00 PM

0

Eric Armstrong wrote:
> Justin Collins wrote:
>> Eric Armstrong wrote:
>>> Saw an archived message yesterday that
>>> said, "when one thread blocks, they all
>>> block".
>>>
>>
>> This hasn't been my experience at all.
> >
> Yay! I'd rather be wrong!
>
>> Do you have a simple example that shows this behavior?
> >
> Below. And now that I'm at work, rather than
> at home, I've been able to determine that it
> works as expected on my Solaris box, but fails
> on Windows XP. (There, the display only updates
> after pressing spacebar or some other key.)
>
> Perhaps the problem is Curses on Windows??
>
<snip code>

Yep, works for me under Linux. I see the countdown without pressing
anything and can exit by pressing 'x'.

Sounds like a Windows issue to me. However, I don't have a way of
testing that :)

-Justin

S Wayne

7/28/2006 10:09:00 PM

0

Tested it with cygwin under Windows XP, and it worked fine. Again,
didn't have to hit spacebar for the thread to start up. Tried with
One-Click Ruby on the same box, and it didn't work.

Windows lack of standard fork is probably the problem here.

Eric Armstrong

7/28/2006 10:38:00 PM

0

N Okia wrote:
> Tested it with cygwin under Windows XP, and it worked fine. Again,
> didn't have to hit spacebar for the thread to start up. Tried with
> One-Click Ruby on the same box, and it didn't work.
>
> Windows lack of standard fork is probably the problem here.
>
Ok, thanks much. One-click Ruby is /so/ convenient.
It's a real pity that threads don't work in it.

I have cygwin running on my machine at home. What's
the best way to get ruby running on it?

That works for me, at least. But the situation pretty
much kills my chances of distributing my timer app to
the world at large. Bummer.

(It's a simple little app. All it does is remind you
periodically to get off your chair and get some
exercise! A compiled executable would be ideal for
distribution, but I wouldn't have minded pointing
people to the one-click installer...)

khaines

7/28/2006 10:58:00 PM

0

S Wayne

7/28/2006 11:06:00 PM

0

> I have cygwin running on my machine at home. What's
> the best way to get ruby running on it?

Startup the cygwin setup.exe program. Select Ruby from the list of
packages to install. Finish the installation.

Eric Armstrong

7/28/2006 11:07:00 PM

0

khaines@enigo.com wrote:
>
> Threads do work on (one-click Windows ruby).
>
> Try this:
>
> -----
>
> def alpha
> Thread.new do
> 'a'.upto('z') {|a| puts a; sleep 2}
> end
> end
>
> def numeric
> Thread.new do
> 1.upto(55) {|n| puts n; sleep 1}
> end
> end
>
> alpha
> numeric
>
> Thread.list.each {|t| t.join}
>
> -----
>
> My guess would be that the way curses is implented on Windows is causing
> the thread blocking behavior.
>
Interesting. I suppose it could be considered a
Curses bug, then.

So how would you implement a simple keyboard-controller
for threads on Windows?

Or are my options restricted to full-blown GUI
or nothing at all?

Chad Perrin

7/28/2006 11:15:00 PM

0

On Sat, Jul 29, 2006 at 08:07:10AM +0900, Eric Armstrong wrote:
>
> So how would you implement a simple keyboard-controller
> for threads on Windows?
>
> Or are my options restricted to full-blown GUI
> or nothing at all?

You could always just implement your own text-based captive interface,
if that's what you really want.

--
CCD CopyWrite Chad Perrin [ http://ccd.ap... ]
"The first rule of magic is simple. Don't waste your time waving your
hands and hopping when a rock or a club will do." - McCloctnick the Lucid

Eric Armstrong

7/28/2006 11:43:00 PM

0

Chad Perrin wrote:
> On Sat, Jul 29, 2006 at 08:07:10AM +0900, Eric Armstrong wrote:
>> So how would you implement a simple keyboard-controller
>> for threads on Windows?
>>
>> Or are my options restricted to full-blown GUI
>> or nothing at all?
>
> You could always just implement your own text-based captive interface,
> if that's what you really want.
>
Riiigghttt....

Given infinite time and energy, I could build everything
I ever wanted or needed, and then some.

I was kind of looking for a simple solution that "just
works" until I can get around to adding the GUI I
eventually plan to add anyway.

It sounds so seductively simple, too: "just implement
my own text-based captive interface". (What the heck
is that, anyway?)
:_)