Ruby thread is buggy while using serialport

Hi all ,
I am using following gems .

gem1.8 list

*** LOCAL GEMS ***

actionmailer (2.3.2)
actionpack (2.3.2)
activesupport (2.3.2)
ruby-ole (1.2.8.2)
ruby-serialport (0.7.0)
spreadsheet (0.6.3.1)
xml-simple (1.0.12)

 I am using modem . By using the serialport I am accessing the modem

port .

while using the .sysread or read get blocked although I
set .read_timeout = -1

But in fork it is working properly .

log is ,irb(main):001:0> require ‘rubygems’
=> true
irb(main):002:0> require ‘serialport’
=> true
irb(main):003:0> sp = SerialPort.new( “/dev/ttyPS1” , 115200 )
=> #SerialPort:0xb796b074
irb(main):004:0> sp.read_timout
NoMethodError: undefined method read_timout' for #<SerialPort:0xb796b074> from (irb):4 irb(main):005:0> sp.read_timeout => 0 irb(main):006:0> sp.read_timeout = -1 => -1 irb(main):007:0> sp.sysread 45 EOFError: end of file reached from (irb):7:insysread’
from (irb):7
irb(main):008:0> sp.sysread 45
EOFError: end of file reached
from (irb):8:in sysread' from (irb):8 irb(main):009:0> sp.sysread 45 EOFError: end of file reached from (irb):9:insysread’
from (irb):9
irb(main):010:0> sp.sysread 45
EOFError: end of file reached
from (irb):10:in sysread' from (irb):10 irb(main):011:0> sp.sysread 45 EOFError: end of file reached from (irb):11:insysread’
from (irb):11
irb(main):012:0> fork {
irb(main):013:1* sp.sysread 45
irb(main):014:1> }
(irb):13:in sysread': end of file reached (EOFError) from (irb):13:inirb_binding’
from (irb):12:in fork' from (irb):12:inirb_binding’
from /usr/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding’
from /usr/lib/ruby/1.8/irb/workspace.rb:52
=> 9425
irb(main):015:0> Thread.new(sp){ |sp|
irb(main):016:1* sp.sysread 43
irb(main):017:1> }
=> #<Thread:0xb7955620 sleep>
irb(main):018:0> Thread.new(sp){ |sp|
irb(main):019:1* p “before”
irb(main):020:1> sp.sysread 43
irb(main):021:1> p “asdf”
irb(main):022:1> }
“before”=> #<Thread:0xb794e8d4 run>
< blocked>

Can any one help me to resolve this?

cheers ,
ashikali

“before”=> #<Thread:0xb794e8d4 run>
< blocked>

My guess is that serialport library has no way of knowing if it has any
data incoming [it has to poll until data arrives?]
If that’s the case, then you might could use fork plus some of the
excellent fork libraries available
http://allgems.ruby-forum.com/gems?search=fork or you’d need to “fix”
serialport so that it’s 1.9 compatible, and then wrap its read call in
an rb_thread_blocking_region, so that it allows other threads to
operate.
GL.
-r

Roger P. wrote:

“before”=> #<Thread:0xb794e8d4 run>
< blocked>

My guess is that serialport library has no way of knowing if it has any
data incoming [it has to poll until data arrives?]
If that’s the case, then you might could use fork plus some of the
excellent fork libraries available
http://allgems.ruby-forum.com/gems?search=fork or you’d need to “fix”
serialport so that it’s 1.9 compatible, and then wrap its read call in
an rb_thread_blocking_region, so that it allows other threads to
operate.
GL.
-r

No I am using frok only . It is working fine no problem .

Also while traping simultaneous SIGCLD also it does not working properly
.

Please fix it and makes rubyserial compactable with thread and Traping
signal .

cheers,
ashik ali

On Aug 12, 6:40 am, Ashikali A. [email protected] wrote:

serialport so that it’s 1.9 compatible, and then wrap its read call in
an rb_thread_blocking_region, so that it allows other threads to
operate.
GL.
-r

No I am using frok only . It is working fine no problem .

Also while traping simultaneous SIGCLD also it does not working properly

You are passing in the same object to different threads. So the
threads call methods on the same object.

Try creating a SerialPort.new inside the thread.

With fork, you generate a seperate ruby process with seperate objects.

I have to inform you another problem . Al though I am using Thread for
one serial
port let us say /dev/ttyPS0 .

It is blocking another serial devive /dev/ttyPS2 . I could not
understand why thread is blocking another serial device too while using
serialport library .

Are they both being read from within the same process, in different
threads?
-r

Roger P. wrote:

I have to inform you another problem . Al though I am using Thread for
one serial
port let us say /dev/ttyPS0 .

It is blocking another serial devive /dev/ttyPS2 . I could not
understand why thread is blocking another serial device too while using
serialport library .

Are they both being read from within the same process, in different
threads?
-r

yes , of course .

Please have look on attached modemThread.rb file .

[email protected]d wrote:

On Aug 12, 6:40�am, Ashikali A. [email protected] wrote:

serialport so that it’s 1.9 compatible, and then wrap its read call in
an rb_thread_blocking_region, so that it allows other threads to
operate.
GL.
-r

No I am using frok only . It is working fine no problem .

Also while traping simultaneous SIGCLD also it does not working properly

You are passing in the same object to different threads. So the
threads call methods on the same object.

Try creating a SerialPort.new inside the thread.

With fork, you generate a seperate ruby process with seperate objects.

I have to inform you another problem . Al though I am using Thread for
one serial
port let us say /dev/ttyPS0 .

It is blocking another serial devive /dev/ttyPS2 . I could not
understand why thread is blocking another serial device too while using
serialport library .

Please go through the attached source code . For your reference .

Ashikali A. wrote:

Roger P. wrote:

I have to inform you another problem . Al though I am using Thread for
one serial
port let us say /dev/ttyPS0 .

It is blocking another serial devive /dev/ttyPS2 . I could not
understand why thread is blocking another serial device too while using
serialport library .

Are they both being read from within the same process, in different
threads?
-r

yes , of course .

Please have look on attached modemThread.rb file .

One port is in same process another one in therad .

please go through the attached modemThread.rb in previous .

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs