![]() |
Threads: Different behavior under Linux and Windows
Hi,
I've tried the sample code below on Ubuntu (7.04) as well as on a Windows XP machine. While under Linux I get the expected result, namely task 1 counting away, under XP task 1 stalls until I enter something, then runs one loop and stalls again. I would have thought that the call to gets in task 2 only blocks task 2, but not task 1. Can anybody please explain this to me and more importantly show me a solution on how to do this so it works under Windows as well? Thanks in advance, Armin require 'thread' t1 = Thread.new{ count = 0 loop{ count += 1 sleep 1 print "T1: #{count}\n" } } t2 = Thread.new{ loop{ a = gets print " T2: a = #{a}\n" } } t1.join t2.join -- Posted via http://www.ruby-forum.com/. |
Re: Threads: Different behavior under Linux and Windows
On Jul 8, 2008, at 8:26 AM, Armin Armbruster wrote: > Can anybody please explain this to me and more importantly show me a > solution on how to do this so it works under Windows as well? it's well known - on windows *all* threads are blocked when the process is blocked on IO. a @ http://codeforpeople.com/ -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama |
Re: Threads: Different behavior under Linux and Windows
ara.t.howard schrieb:
> On Jul 8, 2008, at 8:26 AM, Armin Armbruster wrote: > >> Can anybody please explain this to me and more importantly show me a >> solution on how to do this so it works under Windows as well? > > it's well known - on windows *all* threads are blocked when the > process is blocked on IO. that sure is not because of windows itself... so is there a page explaining why this is so? bye Jochen |
Re: Threads: Different behavior under Linux and Windows
On Jul 8, 2008, at 9:16 AM, Jochen Theodorou wrote: > that sure is not because of windows itself... so is there a page > explaining why this is so? http://groups.google.com/group/ruby-...rch+this+group also, the pickaxe covers this in the 'threads and processes' chapter a @ http://codeforpeople.com/ -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama |
Re: Threads: Different behavior under Linux and Windows
ara.t.howard wrote:
> On Jul 8, 2008, at 9:16 AM, Jochen Theodorou wrote: > >> that sure is not because of windows itself... so is there a page >> explaining why this is so? > > > http://groups.google.com/group/ruby-...rch+this+group > > also, the pickaxe covers this in the 'threads and processes' chapter > > a @ http://codeforpeople.com/ Thanks for your replies Ara. I tried to find it in the pickaxe (second edition), Chapter 11, but I couldn't find anything mentioned about this particular behavior under Windows. Also I tried to follow the discussion on google groups but didn't find a solution described. So now I'm stuck. Here's what I really want to do, maybe someone can show me a solution to this? I'd like to write a little terminal application. 1. Open a serial port 2. Create a sender task that waits for user input on stdin and sends the data out the serial port. 3. Create a receiver task that waits for data coming from the serial port and output it on the screen. Any suggestions? Thanks, Armin -- Posted via http://www.ruby-forum.com/. |
Re: Threads: Different behavior under Linux and Windows
On Jul 8, 2008, at 11:59 AM, Armin Armbruster wrote: > So now I'm stuck. Here's what I really want to do, maybe someone can > show me a solution to this? > I'd like to write a little terminal application. > > 1. Open a serial port > 2. Create a sender task that waits for user input on stdin and sends > the > data out the serial port. > 3. Create a receiver task that waits for data coming from the serial > port and output it on the screen. > > Any suggestions? > > Thanks, > Armin seems like a class case of using select? if select( [stdin, serial], nil, nil, 0.2 ) ... steve shreeve has had some luck using this paradigm: require 'socket' def socketpair if RUBY_PLATFORM.include?("win32") listen = TCPServer.new('127.0.0.1', 0) client = TCPSocket.new('127.0.0.1', listen.addr[1]) server = listen.accept and listen.close [client, server] else UNIXSocket.socketpair end end c,s = socketpair require 'win32/process' info = Process.create( 'app_name' => 'cmd /c "type d:\four_megs.txt & pause"', 'startup_info' => { 'stdin' => c, 'stdout' => c, } ) c.close # needed? to get nonblocking (in a thread) io on windows. regards. a @ http://codeforpeople.com/ -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama |
Re: Threads: Different behavior under Linux and Windows
ara.t.howard wrote:
> to get nonblocking (in a thread) io on windows. > > > > regards. > > a @ http://codeforpeople.com/ Thanks again Ara, I'll give it a try. Armin -- Posted via http://www.ruby-forum.com/. |
Re: Threads: Different behavior under Linux and Windows
On Jul 8, 8:46=A0am, "ara.t.howard" <ara.t.how...@gmail.com> wrote: > On Jul 8, 2008, at 8:26 AM, Armin Armbruster wrote: > > > Can anybody please explain this to me and more importantly show me a > > solution on how to do this so it works under Windows as well? > > it's well known - on windows *all* threads are blocked when the =A0 > process is blocked on IO. It's actually a bug in MRI. JRuby does not exhibit that behavior, for example. Park Heesob posted a patch a short while back that fixes it, too. That patch has already been applied to Sapphire. Regards, Dan |
Re: Threads: Different behavior under Linux and Windows
On Jul 8, 5:19*pm, Jochen Theodorou <blackd...@uni.de> wrote:
> ara.t.howard schrieb: > > > On Jul 8, 2008, at 8:26 AM, Armin Armbruster wrote: > > >> Can anybody please explain this to me and more importantly show me a > >> solution on how to do this so it works under Windows as well? > > > it's well known - on windows *all* threads are blocked when the * > > process is blocked on IO. > > that sure is not because of windows itself... so is there a page > explaining why this is so? > No, is not a Windows problem but MRI Ruby Implementation Issue. Ruby Threads are actually Green Threads (not real threads) so the interpreter need to loop in them to be able to process them. When IO is performed in the same thread (since 1.8 is single threaded) it blocks and stop the green threads to be processed. This is quite old actually, and been discussed several times here and ruby-core (search for Io Thread and gets). There was some changes introduced after p114 (1.8.6) but they needed to be reverted because they introduced some issues on MinGW compilation and Drb, which halt the tests (you can also look for that in ruby-core) At this time there is no solution for it, except to avoid that scenario or jump to something like EventMachine to perform that task (search for EventMachine Console in this forum). HTH, -- Luis Lavena |
Re: Threads: Different behavior under Linux and Windows
On Jul 8, 9:00*pm, Daniel Berger <djber...@gmail.com> wrote:
> On Jul 8, 8:46*am, "ara.t.howard" <ara.t.how...@gmail.com> wrote: > > > On Jul 8, 2008, at 8:26 AM, Armin Armbruster wrote: > > > > Can anybody please explain this to me and more importantly show me a > > > solution on how to do this so it works under Windows as well? > > > it's well known - on windows *all* threads are blocked when the * > > process is blocked on IO. > > It's actually a bug in MRI. JRuby does not exhibit that behavior, for > example. Park Heesob posted a patch a short while back that fixes it, > too. That patch has already been applied to Sapphire. > Hey Dan, can you confirm if that patches make Drb tests stall or pass? similar change introduced in 1.8 (but reverted due this) stall at least for GCC. Maybe we can give another shot at this and merge into 1.8 again. Thank you, -- Luis Lavena |
| All times are GMT. The time now is 10:07 PM. |
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.