"gets" blocking process not thread (in Windows only)
Matt Pattison
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
}
Laurent Julliard
>
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
>> Host your Xerox Software project on CodeX: http://codex.xerox.com
>> Linux@Xerox community: http://xww.linux.world.xerox.com
Hal E. Fulton
From: "Laurent Julliard" <Laurent....@xrce.xerox.com>
To: "ruby-talk ML" <ruby...@ruby-lang.org>
Cc: "Curt Hibbs" <cu...@hibbs.com>
Sent: Thursday, August 01, 2002 9:26 AM
Subject: Re: "gets" blocking process not thread (in Windows only)
> 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.
Hal
Curt Hibbs
>
> From: "Laurent Julliard"
>
> > 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.
Curt
nobu....@softhome.net
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.
--
Nobu Nakada
Paul Brannan
> 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.
Paul
Matt Pattison
> Hi,
>
> 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.
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
nobu....@softhome.net
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().
> > 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.
--
Nobu Nakada
nobu....@softhome.net
At Mon, 5 Aug 2002 20:23:12 +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.
>
> 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.
--
Nobu Nakada
Paul Brannan
> 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().
Could rb_f_select() be changed to work in terms of
WaitForMultipleObjects?
Paul
nobu....@softhome.net
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]).
--
Nobu Nakada
nobu....@softhome.net
At Tue, 6 Aug 2002 23:33:29 +0900,
Paul Brannan wrote:
> > 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().
--
Nobu Nakada