The problem with my program is that (in Windows) gets seems to block the entire
process rather than just the current thread. This program works as expected in
linux, with the poll and process threads running continuously whilst the input
thread is waiting for user input. In windows however all threads appear to halt
as soon as the gets line is reached in the input thread, and only continue once
user input has been given. Can anyone help?
Thanks.
Matt
#This is my program simplified
$input = Thread.new {
while true
command = gets.chomp
^^^^
do_something command
end
}
$poll = Thread.new {
while true
read_data_from_socket_into_queue
end
}
$process = Thread.new {
while true
process_data_from_queue
end
}
The problem with my program is that (in Windows) gets seems to block the entire
process rather than just the current thread. This program works as expected in
linux, with the poll and process threads running continuously whilst the input
thread is waiting for user input. In windows however all threads appear to halt
as soon as the gets line is reached in the input thread, and only continue once
user input has been given. Can anyone help?
Thanks.
Matt
#This is my program simplified
$input = Thread.new {
while true
command = gets.chomp
^^^^
do_something command
end
}
$poll = Thread.new {
while true
read_data_from_socket_into_queue
end
}
$process = Thread.new {
while true
process_data_from_queue
end
}
.
I don’t know if this relates in any way with what Curt Hibbs is trying
to fix for the FreeRIDE project. We are having problems with the way
threads are managed when Ruby is compiled with VC++. It sounds like the
cygwin version runs ok. Which one do you use?
I cc Curt because this might be an interesting test case for its fix.
Laurent
···
–
Laurent JULLIARD - Xerox R&T/SSTC/XPA - Open Source team
At Thu, 1 Aug 2002 16:35:25 +0900, Matt Pattison wrote:
The problem with my program is that (in Windows) gets seems to block the entire
process rather than just the current thread. This program works as expected in
linux, with the poll and process threads running continuously whilst the input
thread is waiting for user input. In windows however all threads appear to halt
as soon as the gets line is reached in the input thread, and only continue once
user input has been given. Can anyone help?
This limitation comes from that the current implementation uses
select() in winsock. It works only for socket handles, so the
others are treated as always immediately readable/writable.
This problem has been known but still unsolved.
And one more issue, windows console reports ready to I/O even
when a mouse event occurs, but ruby doesn’t want it.
In the Cygwin version, the behavior I remember
is this (I may be wrong): gets would not block
in a thread unless the user had already typed
at least one character. (I know, it’s weird, but
that’s Windows.)
So if you did a “timeout” of a thread doing a
gets, the timeout would work if the user had not
typed anything yet, but would fail otherwise.
I don’t know if this relates in any way with what Curt Hibbs is trying
to fix for the FreeRIDE project. We are having problems with the way
threads are managed when Ruby is compiled with VC++. It sounds like the
cygwin version runs ok. Which one do you use?
I cc Curt because this might be an interesting test case for its fix.
This limitation comes from that the current implementation uses
select() in winsock. It works only for socket handles, so the
others are treated as always immediately readable/writable.
This problem has been known but still unsolved.
What issues are there with using rb_f_select() instead?
And one more issue, windows console reports ready to I/O even
when a mouse event occurs, but ruby doesn’t want it.
ReadConsoleInput should return the type of event, so even if a mouse
event occurs, you can ignore it.
The problem with my program is that (in Windows) gets seems to block the entire
process rather than just the current thread. This program works as expected in
linux, with the poll and process threads running continuously whilst the input
thread is waiting for user input. In windows however all threads appear to halt
as soon as the gets line is reached in the input thread, and only continue once
user input has been given. Can anyone help?
This limitation comes from that the current implementation uses
select() in winsock. It works only for socket handles, so the
others are treated as always immediately readable/writable.
This problem has been known but still unsolved.
Is this a problem in the cygwin as well as the vc++ compiled versions of ruby?
I was hoping for a workaround for my problem, so I can get my program working
(it needs to run in Windows).
My other option was to try 1.7.2, but it seems from this email that that won’t
solve my problems.
Matt
···
At Thu, 1 Aug 2002 16:35:25 +0900, > Matt Pattison wrote:
And one more issue, windows console reports ready to I/O even
when a mouse event occurs, but ruby doesn’t want it.
I don’t know if this relates in any way with what Curt Hibbs is trying
to fix for the FreeRIDE project. We are having problems with the way
threads are managed when Ruby is compiled with VC++. It sounds like the
cygwin version runs ok. Which one do you use?
I cc Curt because this might be an interesting test case for its fix.
I think this may be unrelated.
In the Cygwin version, the behavior I remember
is this (I may be wrong): gets would not block
in a thread unless the user had already typed
at least one character. (I know, it’s weird, but
that’s Windows.)
So if you did a “timeout” of a thread doing a
gets, the timeout would work if the user had not
typed anything yet, but would fail otherwise.
It might be related. The one of the test cases I am currently using does not
involve any typing at all – the user doesn’t have to do anything.
in anycase, once I find the problem and have a fix I will test it against
these similar reports.
This limitation comes from that the current implementation uses
select() in winsock. It works only for socket handles, so the
others are treated as always immediately readable/writable.
This problem has been known but still unsolved.
What issues are there with using rb_f_select() instead?
I meant that rb_f_select() is implemented with select().
And one more issue, windows console reports ready to I/O even
when a mouse event occurs, but ruby doesn’t want it.
ReadConsoleInput should return the type of event, so even if a mouse
event occurs, you can ignore it.
I’ve read VC runtime source and know it, but haven’t tried to
implement it. And I don’t know how to determin whether a given handle
is console input.
···
At Fri, 2 Aug 2002 23:02:32 +0900, Paul Brannan wrote:
The problem with my program is that (in Windows) gets seems to block the entire
process rather than just the current thread. This program works as expected in
linux, with the poll and process threads running continuously whilst the input
thread is waiting for user input. In windows however all threads appear to halt
as soon as the gets line is reached in the input thread, and only continue once
user input has been given. Can anyone help?
This limitation comes from that the current implementation uses
select() in winsock. It works only for socket handles, so the
others are treated as always immediately readable/writable.
This problem has been known but still unsolved.
Is this a problem in the cygwin as well as the vc++ compiled versions of ruby?
I was hoping for a workaround for my problem, so I can get my program working
(it needs to run in Windows).
Under cygwin, apparently once you type any key and “gets” block
the process.
My other option was to try 1.7.2, but it seems from this email that that won’t
solve my problems.
No, unfortunately, not yet. In near future, non-blocking IO
might help you, but I don’t know hot to set non-socket IO to
non-blocking mode under Windows.
···
At Mon, 5 Aug 2002 20:23:12 +0900, Matt Pattison wrote:
At Fri, 2 Aug 2002 23:02:32 +0900, > Paul Brannan wrote:
This limitation comes from that the current implementation uses
select() in winsock. It works only for socket handles, so the
others are treated as always immediately readable/writable.
This problem has been known but still unsolved.
What issues are there with using rb_f_select() instead?
I meant that rb_f_select() is implemented with select().
At Tue, 6 Aug 2002 03:33:07 +0900, Paul Brannan wrote:
Could rb_f_select() be changed to work in terms of
WaitForMultipleObjects?
I heard it’s not guaranteed to work with sockets, and
WSAEventSelect() is needed to handle sockets but it set the
socket to non-blocking mode. Currently, non-blocking IO causes
Errno::EWOULDBLOCK exception. We’re still discussing about
NBIO ([ruby-talk:46296]).
ACE (http://www.cs.wustl.edu/~schmidt/ACE.html), which is designed for
working with sockets and doing network programming, uses
WaitForMultipleObjects in its WFMO reactor. If ACE can do it, then I’m
sure Ruby can as well, but not being a Windows programmer, I don’t know
what kinds of issues there might be.
I heard it’s not guaranteed to work with sockets, and
WSAEventSelect() is needed to handle sockets but it set the
socket to non-blocking mode. Currently, non-blocking IO causes
Errno::EWOULDBLOCK exception. We’re still discussing about
NBIO ([ruby-talk:46296]).
I heard it’s not guaranteed to work with sockets, and
WSAEventSelect() is needed to handle sockets but it set the
socket to non-blocking mode. Currently, non-blocking IO causes
Errno::EWOULDBLOCK exception. We’re still discussing about
NBIO ([ruby-talk:46296]).
I wonder what “not guaranteed” means.
It means, it depends on the implementation and MAY work. It just
seems to work with Microsoft’s protocol stack on Windows NT 4.0, but
may not with future version.
ACE (http://www.cs.wustl.edu/~schmidt/ACE.html), which is designed for
working with sockets and doing network programming, uses
WaitForMultipleObjects in its WFMO reactor. If ACE can do it, then I’m
sure Ruby can as well, but not being a Windows programmer, I don’t know
what kinds of issues there might be.
Thank you for the info. At first glance, ACE also seems to bind event
handle to socket handle with WSAEventSelect() to use in
WaitForMultipleObjects().
···
At Tue, 6 Aug 2002 23:33:29 +0900, Paul Brannan wrote: