Are you sure about this?

Yes. Pretty sure.

I've never programmed under Windows,

Don't write this off as a "windows problem".

but under Linux I haven't seen yet any single case when the file descriptor would be closed by the kernel.

You may not have, but others have:

Platform:
 osname=linux, osvers=2.6.24-27-server, archname=i486-linux-gnu-thread
+-multi
 uname='linux vernadsky 2.6.24-27-server #1 smp fri mar 12 01:45:06 ut
+c 2010 i686 gnulinux '
[download]

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:

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 :)

You may not have, but others have

Just to clarify things a little. The page you have referenced, does not provide any specific example where the file descriptor would be closed by something other than the program itself. And I dare to say, that Linux kernel never closes handles opened by application unless application requests it. I don't believe perl would do it either. If you know about such place in perl, please point it out, so that I could avoid this swampy area in the future.

I don't know how the things are done on Windows. But really, if Windows kernel closes your handles behind your back, then it is another reason for me not to use it :) It's a joke of course. But practical outcome is then, that IO::Select is not usable on Windows, but it shouldn't introduce any problems on Linux, as long as the user does the right thing. IMHO.

The page you have referenced, does not provide any specific example

Okay. He made it up; p5p accepted and patched it, just to appease him; and your glorious Linux is perfect.

if Windows kernel closes your handles behind your back, then it is another reason for me not to use it :) It's a joke of course.

There is a joke there all right.

---

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.

RIP Neil Armstrong

If BrowserUK said it, yes, he is sure. And sure to be right. Seriously.

Well, if BrowserUK is so sure, and you know that he is right, then all I'd like to see is the description of situations where the kernel would close your file descriptor without you requesting it. Once you show it to me, I'll be happy to say, that he is right. Until you've done it, I prefer to stick to my own experience. I believe this is fair enough :)

then all I'd like to see is the description of situations where the kernel would close your file descriptor

The mistake you keep making is assuming that it must be the (a) OS kernel that is doing this.

Perl is perhaps a more likely target for responsibility. For example:

{ 
    my $sock = new IO::Socket::INET( 'localhost:12345' );
}
## Here the handle is closed.
[download]

And:

for( 1 .. 2 ){ 
    my $sock = new IO::Socket::INET( 'localhost:12345' );
}    
## The first handle was implicitly closed during the second iteration.
[download]

These examples probably won't convince you, because the scoping is too obvious. But scoping isn't always so obvious, especially when programming in the "global state and gotos" style often required by event-driven architectures.

Similarly, this is normally perfectly fine:

...
    my $client = $svr->accept;
    async {
        ## do things with $client
    }->detach;
[download]

But, this usually not:

...
    my $client = $svr->accept;
    async {
        sleep 10;
        ## attempts to use $client fail
    }->detach;
[download]

The reason is that before the thread gets around to using its copy of the client handle, the parent thread has accepted another client. Now imagine the sleep isn't a programmed delay, but rather one caused by system loading (cpu; memory; IO) preventing the new thread getting up and running in a timely manner, so that the parent thread implicitly overwrite (and therefore closes) $client before the child thread gets to the point where it increments the reference count.

But you'll dismiss that as a "threads-issue".

I can't offer you an explanation of the linux example I cited -- I don't know the guy, nor do I do Linux -- but if the p5p guys took his perlbug seriously enough to patch perl; that's good enough for me to believe that it was a real issue.

I can also find other references to linux sockets mysteriously going awol, even outside of Perl. What I cannot do is pass judgement on the validity of the claims.

But even if every single occasion when an attempt is made to remove a closed file handle from an IO::Select object is down to programmer error; silently doing nothing and thus screwing the entire select loop is ... is ... shall we stick with: not very friendly.

---

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.

RIP Neil Armstrong