BrowserUk has asked for the wisdom of the Perl Monks concerning the following question:
Can anyone demonstrate that IO::Select actually works?
If so, are you willing to post a demo server and client?
Note: I'm not interested in code that uses select directly; or alternatives like glib or POE. I'm specifically trying to determine if IO::Select actually works anywhere other than on my system.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Does IO::Select work? (Problem partially resolved)
by BrowserUk (Patriarch) on Oct 21, 2012 at 10:56 UTC | |
The problems (long term; I previously put it down to my not using the module correctly), I've been encountering with IO::Select come down to the fact that the module relies upon fileno to do its thing. Where this falls down is if the handle gets closed before the program gets around to remove()ing it from the IO::Select object. For example, if you code:
You won't get any errors or warnings, but your server simply will not work correctly. Because the socket was closed before it was removed, fileno( $client ) will return undef and the attempt to remove the handle from the select object fails. SILENTLY! After that, pretty much nothing works properly. I realise that the above code can be seen to be in error, and switching the order of the two statements makes it work. But that doesn't cover all the bases, because it is perfectly possible for a file handle to get closed without the program doing it explicitly. This turns out to be a known problem that was reported in 2010, previously reported in 2005 and (apparently) probably existed since circa. 1998.. And, despite that the RT suggests a fix has been applied in May 2010, inspecting the CPAN source shows that it will still fail -- silently -- today. Even a simple warning that you've made an attempt to remove a closed handle would help; but it isn't hard to fall back on a linear search of the array of file handles and relate their position in the array back to a fileno and hence bit vector bit. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] |
by Anonymous Monk on Oct 21, 2012 at 11:02 UTC | |
| [reply] |
by BrowserUk (Patriarch) on Oct 21, 2012 at 11:23 UTC | |
Hm. So, the CPAN source is *NOT* the place to go for the latest version. That sucks! And, according to IO::Select: allow removal of IO::Handle objects without fileno the fix was implemented in January 2011, and I am using 5.16:
which I'm pretty sure came out after that and still seeing the problem? Perhaps because the 'fix', removes the handle from the array, but fails to remove it from the bitmask:
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] [select] |
by andal (Hermit) on Oct 22, 2012 at 07:32 UTC | |
But that doesn't cover all the bases, because it is perfectly possible for a file handle to get closed without the program doing it explicitly. Are you sure about this? Well, I've never programmed under Windows, but under Linux I haven't seen yet any single case when the file descriptor would be closed by the kernel. The rule is simple, if the user opens a file descriptor, the user has to close it. There could be libraries that close it for you, but those libraries are running in the application space. So, if you make sure, that you remove file descriptor from "select" before you close it, then things work fine. As to example, I've never used IO::Select module, but many years ago I've created more or less simple module that uses "select" directly. This module still works for many of my application, even though I consider it to be very poor. You can get it at http://vandal.sdf-eu.org/NetHandling.pm if you want. I guess the main reason why one can't find good examples of using "select" is just the fact, that it is not that simple. To make things really working, one has to take into account many details. As result the code becomes hard to understand. Actually, if one tries to implement the same stuff using threads, then at the end the code would become equally complex and hard to understand. So I don't believe one would be able to provide simple but yet robust example of using select or threads for networking. | [reply] |
by BrowserUk (Patriarch) on Oct 22, 2012 at 08:18 UTC | |
As to example, I've never used IO::Select module, but many years ago I've created more or less simple module that uses "select" directly. This module still works for many of my application, even though I consider it to be very poor. You can get it at http://vandal.sdf-eu.org/NetHandling.pm if you want. Thanks for teh offer, but the way I eventually stopped writing off my long term lack of success with IO::Select as "user error" was by re-implementing (most) of the API without reference to the module source: <Reveal this spoiler or all in this thread>
I guess the main reason why one can't find good examples of using "select" is just the fact, that it is not that simple. Maybe, but wrapping over some of the low-level nitty-gritty in an IO:Select-type module certainly makes it easier. But if there has been a latent bug in that module for the last 12 or more years that prevented people's attempts from working, it would have had a significant effect upon the availability of good examples. And given that there are plenty of examples of many other things that are at least as complex, I find that a pretty persuasive argument for that inhibitory effect. I've never really needed to use select for serious work -- I find threading far simpler, more intuitive and more powerful -- on windows at least -- so my previous attempts have been half-hearted -- usually with a view to demonstrating the virtues of threading over the select model -- and so I never had any real incentive to work past the problems. Now I have understood the problem that has dogged my attempts for years, I feel the need to write a (pair of) full-featured servers. In part so I know I have done so. In part to allow me to make the real-world comparisons and measurements that will test my gut feel hypothesis about the relative merits of the two approaches. Watch this space. (But don't hold your breath :) With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] [select] |
by andal (Hermit) on Oct 22, 2012 at 09:06 UTC | |
by BrowserUk (Patriarch) on Oct 22, 2012 at 09:39 UTC | |
by sundialsvc4 (Abbot) on Oct 22, 2012 at 13:19 UTC | |
| |
by andal (Hermit) on Oct 23, 2012 at 08:42 UTC | |
by BrowserUk (Patriarch) on Oct 23, 2012 at 10:11 UTC | |
| |
Re: Does IO::Select work? Anywhere?
by ikegami (Patriarch) on Oct 21, 2012 at 08:48 UTC | |
One-way comm:
| [reply] [d/l] [select] |
by Athanasius (Archbishop) on Oct 21, 2012 at 10:09 UTC | |
Doesn’t work for me. :-( I copied-and-pasted the code into a file named “344_SoPW.pl” and ran it with the following results:
(Had to Control-C as it just hung.) My configuration:
Hope this info is useful, Athanasius <°(((>< contra mundum | [reply] [d/l] |
by Anonymous Monk on Oct 21, 2012 at 10:30 UTC | |
:) Really, you don't have /dev/null on windows? Use File::Spec->devnull naturally fixing those portability issues , select loop is forever
Perl version: v5.14.1 on MSWin32 Carp - 1.26 Devel::VersionDump - 0.02 Exporter - 5.66 File::Spec - 3.33 File::Spec::Unix - 3.33 File::Spec::Win32 - 3.33 IO::Select - 1.20 IPC::Open3 - 1.09 Symbol - 1.07 constant - 1.21 strict - 1.04 vars - 1.02 warnings - 1.12 warnings::register - 1.02 | [reply] [d/l] |
by BrowserUk (Patriarch) on Oct 21, 2012 at 10:18 UTC | |
Doesn’t work for me. ... Windows ... It won't. Pipe handles aren't selectable under windows -- which makes it a pretty useless demo for anyone who uses windows. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Re: Does IO::Select work? Anywhere?
by zentara (Archbishop) on Oct 21, 2012 at 12:08 UTC | |
Server:
And a general purpose client:
I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh | [reply] [d/l] [select] |
by BrowserUk (Patriarch) on Oct 21, 2012 at 13:07 UTC | |
This code runs rock solid for me on Linux, it's about as simple an IO::Select example that you can get. Thank you. But ... :) If there is a complete, correct example out there, I'm damned if I can find it. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
by zentara (Archbishop) on Oct 21, 2012 at 15:16 UTC | |
:-) Yeah, that is why I like using the eventloop method that Glib and Wx use, where their eventloop can detect conditions like IN , HUP, ERR, etc. I would think if you looked at the c based source code for glib's io::watch method, you will probably find the c code, which allows the eventloop's intelligence to report back IN or HUP, or ERR. From some discussion I remember from back in my c experiments, there are some sort of error flag set, with values like eagain, einttr, etc. See blocking sockets . That code looks like it could be rewritten in a Perl script, although you may need require 'sys/ioctl.ph';. P.S. See the low level Perl code, multiplexing server at perl examples I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh | [reply] |
by BrowserUk (Patriarch) on Oct 21, 2012 at 15:56 UTC | |
by zentara (Archbishop) on Oct 22, 2012 at 10:35 UTC | |
| |
Re: Does IO::Select work? Solution
by zentara (Archbishop) on Oct 24, 2012 at 12:58 UTC | |
I run the server, then start one conventional client, then your hanger-script, then a second client. All works well. Is this the mythical Holy Grail select script that you have been looking for? :-) It may not be perfected yet, but it works non-blocking here. Server:
The client:
And your hanger-test script
I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh | [reply] [d/l] [select] |
by Mr. Muskrat (Canon) on Oct 25, 2012 at 17:58 UTC | |
When I only care about readable handles, I prefer to use can_read rather than select. my @new_readable = $readable_handles->can_read(0); | [reply] [d/l] |
by BrowserUk (Patriarch) on Oct 24, 2012 at 20:22 UTC | |
Is this the mythical Holy Grail select script that you have been looking for? Not really. Start your server and before you connect anything, check top. 100% cpu when doing nothing isn't nice. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
by zentara (Archbishop) on Oct 25, 2012 at 10:25 UTC | |
Is this 100% cpu usage really 100%? If so, how come all my other apps are still as responsive as ever? I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh | [reply] |
by tye (Sage) on Oct 25, 2012 at 13:16 UTC | |
by zentara (Archbishop) on Oct 25, 2012 at 15:42 UTC | |
Re: Does IO::Select work? Anywhere?
by zentara (Archbishop) on Oct 24, 2012 at 12:04 UTC | |
I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh | [reply] |
by BrowserUk (Patriarch) on Oct 24, 2012 at 12:24 UTC | |
Do you think those sorts of tests on a select socket would be able to detect your "eternal a" script, and dispose of it? The solution is to not use readline, or anything that blocks waits for a terminator that may never arrive. Instead, use recv or sysread and get whatever is available when can_read() tells you there is something there, and accumulate those somethings until a newline (or other terminator) is seen before taking action. In the case of the client that never sends a terminator, it will eventually time out if it never transmits anything more. The most effective DOS strategy against badly written multiplexing servers is to send one character every (say) 890 seconds (default timeouts are often 900), but to never send a terminator. Another strategy is to send huge packets that overrun memory. For badly designed C code, that usually results in the classic buffer overrun. For a perl program, it can actually be worse. As Perl will just keep increasing the size of the scalar, it can put the server into swapping and bring everything to a crawl without actually blowing it out of the water. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
by Anonymous Monk on Oct 24, 2012 at 12:22 UTC | |
| [reply] [d/l] |