ruby threads? the point?
in [Ruby]
|
From: Eric Armstrong on 28 Jul 2006 12:47 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?
From: Justin Collins on 28 Jul 2006 12:59 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
From: Eric Armstrong on 28 Jul 2006 17:18 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
From: Justin Collins on 28 Jul 2006 17:36 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
From: N Okia on 28 Jul 2006 18:09
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. |