[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Asyn sockets

Eustaquio Rangel de Oliveira Jr.

3/17/2005 8:08:00 PM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello there!

Is there some feature in Ruby like the Java SocketChannels or Python
asynchat/asyncore?
I mean, async sockets to make that kind of server program where I don't
need one thread for every connected client.

Thanks!

- ----------------------------
Eustáquio "TaQ" Rangel
eustaquiorangel@yahoo.com
http://b...
Usuário GNU/Linux no. 224050
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail....

iD8DBQFCOeOib6UiZnhJiLsRApgWAJ0ZNroG61tBfcTdF67GVq23CHciLQCeMAEj
Cq9MB+ge1JH9DTT+FOTrPcY=
=5cK3
-----END PGP SIGNATURE-----
7 Answers

gabriele renzi

3/18/2005 10:29:00 AM

0

Eustaquio Rangel de Oliveira Jr. ha scritto:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello there!
>
> Is there some feature in Ruby like the Java SocketChannels or Python
> asynchat/asyncore?
> I mean, async sockets to make that kind of server program where I don't
> need one thread for every connected client.
>
> Thanks!
>

I guess you are thinking of IO#select(). Notice that ruby threads are
userspace ones, and every IO access is actually multiplexed to async
request like python's asyncore.

Eustaquio Rangel de Oliveira Jr.

3/18/2005 10:50:00 AM

0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

gabriele renzi wrote:

| I guess you are thinking of IO#select(). Notice that ruby threads are
| userspace ones, and every IO access is actually multiplexed to async
| request like python's asyncore.

Thanks! :-)

- ----------------------------
Eustáquio "TaQ" Rangel
eustaquiorangel@yahoo.com
http://b...
Usuário GNU/Linux no. 224050
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail....

iD8DBQFCOrIpb6UiZnhJiLsRAuj9AJ97K7mfqXe6W/4YIfaMqxwKczaSoACffBt1
uAYG/jT3F5LwtcGbtThPf3E=
=R7TT
-----END PGP SIGNATURE-----

Ed Wildgoose

3/25/2005 1:27:00 PM

0


> I guess you are thinking of IO#select(). Notice that ruby threads are
> userspace ones, and every IO access is actually multiplexed to async
> request like python's asyncore.

What about non-blocking connects though?

Yohanes Santoso

3/25/2005 2:04:00 PM

0

Ed Wildgoose <ed@wildgooses.com> writes:

>> I guess you are thinking of IO#select(). Notice that ruby threads are
>> userspace ones, and every IO access is actually multiplexed to async
>> request like python's asyncore.
>
> What about non-blocking connects though?

The current ruby implementation silently switch the IO operating mode
to non-blocking prior to connect (and of course restore the original
mode afterwards).

So, whether you are setting the fd to NB mode yourself or not, your
connect won't block (assuming your OS supports NB operation).

YS.
--
http://micro...

Ed Wildgoose

3/25/2005 10:33:00 PM

0

>> What about non-blocking connects though?
>
> The current ruby implementation silently switch the IO operating mode
> to non-blocking prior to connect (and of course restore the original
> mode afterwards).
>
> So, whether you are setting the fd to NB mode yourself or not, your
> connect won't block (assuming your OS supports NB operation).

So lets get specific...

On win32 if I open a TCP socket will it will return immediately? Presumably
then I won't find out the success of failure of the socket open until some
later time when the async open completes?

I'm interested because I have a perl network app and am thinking of
rewriting in ruby, but I have had to already invest quite a lot of time
understanding the peculiarities of sockets under windows and perl...

Thanks

Ed W

Yohanes Santoso

3/26/2005 8:39:00 PM

0

Ed Wildgoose <ed@wildgooses.com> writes:

>> So, whether you are setting the fd to NB mode yourself or not, your
>> connect won't block (assuming your OS supports NB operation).

The word "your" above is misleading (and wrong?). It should be "the
connect operation you initiated from the ruby land, will not block the
ruby vm.

> On win32 if I open a TCP socket will it will return immediately?

No

> Presumably then I won't find out the success of failure of the
> socket open until some later time when the async open completes?

WRT your ruby code, the Socket#connect call won't return until either
it is successful or failed.

What I meant above is: the ruby vm will not be blocked just because
you do a Socket#connect in blocking mode. The ruby vm will be able to
schedule other threads to run while it waits for the success/failure
of the connect syscall.

This means (from ruby land), if it takes x seconds to call the connect
syscall and wait for its result, then doing 100 Socket#connect on 100
threads will take less than 1000*x seconds.

YS.

Ed W

3/27/2005 9:14:00 AM

0

>>Presumably then I won't find out the success of failure of the
>>socket open until some later time when the async open completes?
>
>
> WRT your ruby code, the Socket#connect call won't return until either
> it is successful or failed.
>
> What I meant above is: the ruby vm will not be blocked just because
> you do a Socket#connect in blocking mode. The ruby vm will be able to
> schedule other threads to run while it waits for the success/failure
> of the connect syscall.

Aha. Well in that case I would call this a "blocking" connect. The
point is that I know have to start to use a bunch of threads to do
simple stuff like opening some sockets.

In my perl code it's admitedly a complete bear to get it working in
async mode under win32, but once it's done I now have just one thread
and an io:select kernel which spins round and round scheduling stuff to
run. None of the individual operations are expected to take any
significant time so I don't need the timeslicing ability of adding these
ops to seperate threads/processes.

Is there a place to propose an addition to the API, like adding a
"blocking" attribute to the socket library? Seems that this could be a
very useful addition for a (small?) number of people?

Anyway, haven't written anything yet, but I love the look of Ruby. Will
schedule some smaller projects to be written in it for kicks

Thanks for your answers

Ed W