Asyn sockets

[Eustaquio Rangel de Oliveira Jr.]

-----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
(e-mail address removed)
http://beam.to/taq
Usuário GNU/Linux no. 224050
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

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

 

[gabriele renzi]

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.]

-----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
(e-mail address removed)
http://beam.to/taq
Usuário GNU/Linux no. 224050
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

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

 

[Ed Wildgoose]

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]

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.

 

[Ed Wildgoose]

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

 

[Ed W]

Presumably then I won't find out the success of failure of the

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