The concept would not work in future versions, as the basic concept is that he has a single filehandle ($client) that represents more than one socket, if sharing of filehandles becomes implemented, that won't change the fact that $client will only contain the most recently connected client, not all of them.

jasonk, you are a little bit wrong about Anonymous Monk's code, although his code has problem, but not exactly as you pointed out.

First play with two pieces od demos I created:

use threads;
use threads::shared;

use strict;

my $a : shared = 1;

{
    #our $a = 2;
    print $a;
}
[download]

And this one:

use threads;
use threads::shared;

use strict;

my $a : shared = 1;
threads->create(\&display);
<STDIN>;

sub display {
    #our $a = 2;
    print $a;
}
[download]



Try to play with that line I commented out, try to comment it and uncomment it, see what you would get.

1. If you comment out that line (doesn't matter which version of my demo, the one with two threads, or the one with actually one thread), you would get 1, because $a refers to the shared variable, and its value is 1.
2. If you uncomment that line, you would get 2, because now $a refers to our $a.
Now let's carefully examine Anonymous Monk's code together. You can see that, before he call accept(), he actually declared $client in the same scope, and passed the newly accepted socket to his start_thread function, so he does stored multiple connections.

However, in his begin function, he used the shared $client, which is not initialized.

More important, we should look at this from a conceptual view, not focus on his code too much (his code has some bugs, but that does not mean that what in his mind is wrong.)

From a conceptual view, as I said in my original reply, to share socket among threads will not be a problem for Perl, and it should be shared just like any other object. Just wait for bless to be fixed.