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?
Eric A. wrote:
What is the point of the having “threads”
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
Justin C. wrote:
Eric A. 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
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 A. wrote:
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??
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
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…)
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.
On Sat, 29 Jul 2006, Eric A. wrote:
Ok, thanks much. One-click Ruby is /so/ convenient.
It’s a real pity that threads don’t work in it.
Threads do work on it. 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.
Kirk H.
[email protected] wrote:
Threads do work on (one-click Windows ruby).
def numeric
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 P. wrote:
On Sat, Jul 29, 2006 at 08:07:10AM +0900, Eric A. 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?)
:_)
On Sat, Jul 29, 2006 at 08:42:58AM +0900, Eric A. wrote:
my own text-based captive interface". (What the heck
is that, anyway?)
What is what – a captive interface? It’s an interface that forces you
to do everything you want to do with a program without letting you do
other things between minor operations. For instance, a non-captive CLI
is something like apt-get on Debian GNU/Linux or ipconfig on Windows,
while a captive interface is something like an ncurses-based program
that starts, takes input, gives output, and doesn’t go away until you’re
all done with it.
On Sat, Jul 29, 2006 at 08:07:10AM +0900, Eric A. 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.
Eric A. wrote:
Interesting. I suppose it could be considered a
Curses bug, then.
My experience has been that IO is blocking in Ruby/Windows. Just try
creating a background thread to insert into an MSSQL server through
WIN32OLE+ADO. It’s an exercise in futility.
I even had a seperate process that exposed a ThreadQueue in the DRb
server for the client to push onto, but while the server was busy, the
client was blocked. In a completely different process, only connected
through DRb!
I can appreciate the general Ruby community attitude that OS-Threading
isn’t absolutely vital when you’re on Linux and have fork at the
ready, but under Windows it’s very painful and really limits the types
of applications you can build with Ruby (with a reasonable amount of
effort) IME.
Ezra Z. wrote:
Have a look at the highline gem. Its a great library for console
based question and menu systems. And it works with threading.
Could be a useful option. Thanks for the tip.
Found it’s main page at
http://highline.rubyforge.org/
Is there a starter app anywhere? I see the APIs.
I’m guessing I do something like this:
ifc = HighLine.new
ifc.say “xyz”
response = ifc.ask “xyz”
But it would be nice to have a little scaffolding
to start from…
On Jul 28, 2006, at 4:42 PM, Eric A. wrote:
Riiigghttt…
is that, anyway?)
:_)
Eric-
Have a look at the highline gem. Its a great library for console
based question and menu systems. And it works with threading.
-Ezra
N Okia wrote:
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.
Spectacular. Didn’t know about the program.
Thanks much.
On Sat, 29 Jul 2006, Sam S. wrote:
I can appreciate the general Ruby community attitude that OS-Threading
isn’t absolutely vital when you’re on Linux and have fork at the
ready, but under Windows it’s very painful and really limits the types
of applications you can build with Ruby (with a reasonable amount of
effort) IME.
This has been brought up at previous Ruby Conferences. It is my
understanding that it is being worked on. So, relax and watch the
blinking lights.
– Matt
It’s not what I know that counts.
It’s what I can remember in time to use.
Sam S. wrote:
My experience has been that IO is blocking in Ruby/Windows. Just try
creating a background thread to insert into an MSSQL server through
WIN32OLE+ADO. It’s an exercise in futility.
Ah. That explains why the two counter threads
worked. There was no I/O going on. But outside
of computational supercomputers, there is zero
point in having threads if they don’t let you
keep doing things while waiting for I/O.
…under Windows it’s very painful and really limits the types
of applications you can build with Ruby…
I’m forced to agree. My little application is dead in the
water. Windows users would have been a major market for it.
It would have helped drive ruby installs, which would have
helped to drive awareness. Similarly with game programs,
music programs, and a wide variety of other interesting
applications.
This limitation is a severe shot in the foot with respect
to platform independence.
On Sat, 2006-07-29 at 06:18 +0900, Eric A. wrote:
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.)
Here is an improvisation to your code. This automatically exits at the
end of the set timer, rather than wait for a ‘q/Q’ from the user.
Greetings,
JS
require ‘curses’
require ‘thwait’
count = ARGV[0] ? ARGV[0].to_i : 100
Curses.addstr “I am going to count #{count}. Press ‘q’ or ‘Q’ to
exit.\n”
Curses.refresh
threads = ThreadsWait.new
timer_thread = Thread.new do
count.downto(1) do |i|
Curses.addstr(".")
Curses.refresh
sleep 1
end
end
threads.join_nowait timer_thread
wait_thread = Thread.new do
while true
c = Curses.getch
case c
when ?q, ?Q
return true
end
end
end
threads.join_nowait wait_thread
begin
threads.next_wait
ensure
Thread.kill(timer_thread)
Thread.kill(wait_thread)
end
I hate to make a plug here, but threads under JRuby are native and a
single
one blocking on IO will not prevent others from running. It’s still
quite a
bit slower than C Ruby, but for many applications it’s definitely fast
enough.
Ruby 2.0 is supposed to have native threads too, but I know that 18+
months
is a long time to wait.