[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

"loop do IO.select([io], nil, nil)" eats 95% of CPU, any other way?

Iñaki Baz Castillo

3/26/2008 4:35:00 PM

SGksIHdoaWNoIGlzIHRoZSBtb3N0IGVmZmljaWVudCB3YXkgb2YgcmVjZWl2aW5nIGFuZCBwcm9j
ZXNzaW5nIGRhdGEKZnJvbSBhIG5ldHdvcmsgc29ja2V0PwoKSSB1c2UgR1NlcnZlciBpbiB0aGlz
IGNvbW1vbiB3YXk6CgotLS0tLS0tLS0tLS0tLQpjbGFzcyBNeVNlcnZlciA8IEdTZXJ2ZXIKICAg
IGRlZiBzZXJ2ZShpbykKICAgICAgICBsb29wIGRvCiAgICAgICAgICAgICAgaWYgSU8uc2VsZWN0
KFtpb10sIG5pbCwgbmlsKQogICAgICAgICAgICAgICAgICAuLi4uCi0tLS0tLS0tLS0tLS0tCgpB
ICJ0b3AiIHNheXMgdG8gbWUgdGhhdCBSdWJ5IGlzIGVhdGluZyBtb3JlIHRoYW4gOTAlIG9mIENQ
VSBhbmQgdGhlcmUKaXMgbm8gY29ubmVjdGlvbnMgeWV0Li4uIDooCkFueSBvdGhlciBzdWdnZXN0
aW9uPwoKUmVhbGx5IHRoYW5rcyBhIGxvdC4KCgoKLS0gCknDsWFraSBCYXogQ2FzdGlsbG8KPGli
Y0BhbGlheC5uZXQ+Cg==

5 Answers

Robert Klemme

3/26/2008 6:36:00 PM

0

On 26.03.2008 17:34, Iñaki Baz Castillo wrote:
> Hi, which is the most efficient way of receiving and processing data
> from a network socket?
>
> I use GServer in this common way:
>
> --------------
> class MyServer < GServer
> def serve(io)
> loop do
> if IO.select([io], nil, nil)
> ....
> --------------
>
> A "top" says to me that Ruby is eating more than 90% of CPU and there
> is no connections yet... :(
> Any other suggestion?
>
> Really thanks a lot.

Why don't you simply use blocking IO?

robert

James Tucker

3/26/2008 9:17:00 PM

0


On 26 Mar 2008, at 19:53, John Carter wrote:
> As a little side comment... You can _always_ take a program written
> around a select & state machine and make it multi-threaded doing
> blocking I/O or conversely refactor a multi-threaded app into a select
> based state machine.

Assuming of course that a block in one thread won't block all other
threads.

Iñaki Baz Castillo

3/26/2008 10:49:00 PM

0

El Mi=C3=A9rcoles, 26 de Marzo de 2008, John Carter escribi=C3=B3:

> Hmm.From the "man select" page...
>
> timeout is an upper bound on the amount of time elapsed before
> select() returns. It may be zero, causing select() to return
> immediately. (This is useful for polling.) If timeout is NULL
> (no timeout), select() can block indefinitely.
>
> My guess is you have one too few nil's in there and the default timeout is
> 0 not nil.

Yes, true, with "strace" I see:

=2E..
sigprocmask(SIG_BLOCK, NULL, []) =3D 0
sigprocmask(SIG_BLOCK, NULL, []) =3D 0
sigprocmask(SIG_BLOCK, NULL, []) =3D 0
sigprocmask(SIG_BLOCK, NULL, []) =3D 0
sigprocmask(SIG_BLOCK, NULL, []) =3D 0
select(4, [3], [], [], {0, 0}) =3D 0 (Timeout) <---
sigprocmask(SIG_BLOCK, NULL, []) =3D 0
sigprocmask(SIG_BLOCK, NULL, []) =3D 0
sigprocmask(SIG_BLOCK, NULL, []) =3D 0
sigprocmask(SIG_BLOCK, NULL, []) =3D 0
sigprocmask(SIG_BLOCK, NULL, []) =3D 0
=2E..


but I've tryed with all the values in the 4=C2=BA parameter of "IO.select":
IO.select([io], nil, nil, 0)
IO.select([io], nil, nil, nil)
IO.select([io], nil, nil, X)

and nothing changes, in all cases I see the same with "strace". =C2=BF?=C2=
=BF



> to discover why linux is such a great place to develop on.... you can
> _always_ find out what is really going on with any program.

Sure I use Linux... what else? XD


> As a little side comment... You can _always_ take a program written
> around a select & state machine and make it multi-threaded doing
> blocking I/O or conversely refactor a multi-threaded app into a select
> based state machine.

Of course I need to read a lot about IO methods :)


Thanks a lot.


=2D-=20
I=C3=B1aki Baz Castillo

Iñaki Baz Castillo

3/27/2008 2:52:00 AM

0

El Jueves, 27 de Marzo de 2008, John Carter escribi=C3=B3:

> My guess is if you include the read statements you get something like
> this... read(3, "", 1000) =3D 0
> Which means (according to "man 2 read")

Which lib package must I install to get these man pages? I don't find them =
in=20
a Debian with default installation.


> =3D=3Dtest.rb=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> loop do
> begin
> open( "foofi") do |f|
> loop do
> p select([f],nil,nil,500000)
> p f.sysread(1000)
> end
> end
> rescue EOFError =3D> details
> p details
> end
> end
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Works as expected...
>
> But...
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> open( "foofi") do |f|
> loop do
> p select([f],nil,nil,500000)
> p f.sysread(1000)
> end
> end
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Bombs out with EOFError
>
> but curiously
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> open( "foofi") do |f|
> loop do
> p select([f],nil,nil,500000)
> p f.read(1000)
> end
> end
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Exhibits exactly the behaviour you describe.


> So it all behaves according to plan... just not your plan... :-))


Thanks a lot for so great information, it's really a good explanation.=20
Tomorrow I'll review all of it.


Thanks a lot for all and best regards.

=2D-=20
I=C3=B1aki Baz Castillo

Marcelo

3/27/2008 2:57:00 AM

0

T24gV2VkLCBNYXIgMjYsIDIwMDggYXQgODo1MSBQTSwgScOxYWtpIEJheiBDYXN0aWxsbyA8aWJj
QGFsaWF4Lm5ldD4gd3JvdGU6Cgo+ICBXaGljaCBsaWIgcGFja2FnZSBtdXN0IEkgaW5zdGFsbCB0
byBnZXQgdGhlc2UgbWFuIHBhZ2VzPyBJIGRvbid0IGZpbmQKPiAgdGhlbSBpbiBhIERlYmlhbiB3
aXRoIGRlZmF1bHQgaW5zdGFsbGF0aW9uLgoKIG1hbnBhZ2VzLWRldi4KCiBNYXJjZWxvCg==