Re^4: threads with shared variables across multiple instances of a module

[zerg13new]

can i share the whole hash ?? a can't push in my shared hash pair like this:

"192.168.0.1:3128" => $client

$client is a local (defined with "my") variable (socket)

part of my code:

.....
use strict;
use Socket;
use threads;
use threads::shared;
.......
my %clients :shared;
......
my $server = IO::Socket::INET -> new(.....);
.....
while( my $client = $server -> accept ) {
.....
###############
in next 2 strings i'm wall!!! i don't know how push $socket (it's refe
+rence to NANDLE, isn't it?!) in shared hash %clients, and then get it
+ back like a handle!!
the best error i've had, was "Bad file descriptor"
################
$clients{ "$client_ip:$client_port" } = *client{IO}; # add new socket 
+to %client
syswrite( $$qwe{IO}, "hi, how are you??") || die ":$! _ $@";
.....
}

help me please, desparing

[BrowserUk]

This  *client{IO}; is invalid syntax when $client is a lexical.

It would have to be *{ $client }{IO}.

But that still won't help you because of an (unnecessary) restriction that doesn't allow you to store globs, (or references to globs) into shared scalars.

There are two ways to share globs (filehandles sockets etc.) between threads:

1. Share the file number between threads and dup() the associated filehandle into existance in teh target thread(s):

   my %clients :shared;
   while( my $client = $server->accept;
       $clients{ client } = fileno( $client );
   }
   ...
   ## within the threads
   my $client;
   my $fileno = $clients{ client };
   open $client, "+<&$fileno" or die ... ## dup() the the glob from the f
   +ileno
   ## use $client
   

2. Allow the thread access to the client handle via cloned closure:

   while( my $client = $server->accept ) {
       async{
           while( my $in = <$client> ) {
               print $client $in; ### simple echo server
           }
       }->detach;
   }
   

I've never understood this restriction. The fact that a glob can be successfully shared via the latter method suggests strongly that the restriction both artifical (they just decided to reject glob(ref) assignments to shared scalars--and the code supports this); and unnecessary.

But those that should know the answer to why this restriction was established and persists, have chosen not to answer that question.