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://beam.to/taq
Usuário GNU/Linux no. 224050
Eustaquio Rangel de Oliveira Jr. ha scritto:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Hello 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.
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
Usuário GNU/Linux no. 224050
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?
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.
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 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.
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