Re: Keeping an INET socket inside a shared object

[Superfox il Volpone]

Hi there,
Thank you for replies.

oh, I did not expect such situation when I started to code my project. So basically I have a bunch of workers that should offload the work on different machines, a master that schedule the work to the remote workers, and a set of users that send work to be done and query the current status. The communication is intrinsically non deterministic, because workers can report their status, or the raise of issues, to the master at different times, while the master can demand different services to workers.

In the master, I thought to set a different handler to each worker or user. As the handlers should cooperate each other and keep a consistent view in every moment, I did immediately model them as shared objects. Eventually, since each handler should "own" its connection socket, it came up pretty natural the willing to associate the socket with its handler. But the object is shared for its own nature, while the socket is not, therefore my struggle.

The second motivation is, I imagine, conceptual. Because if TCP is sequentially bidirectional (that`s new to me), it is conceptually bidirectional, i.e. there are two different untied streams to read/write, which allow two different flows to take place...

I did a step ahead, being able to share a socket among certain threads. I guess there was a problem of scope, the socket was destroyed in the ctor itself. This is my updated code:

our %SharedSockets; # keep the created sockets to survive

sub new(){
    my $class = shift;
    die("Not an instance method") if ref($class);

    
    my $self = &share(bless({},$class));
    $self->{"closed"} = 0;
    
    my $socket = new IO::Socket::INET(@_) or die("SharedSocket $!");
    $socket->autoflush(1);

    
    $self->{"closed"} = 0;
    $self->{"socket_fd"} = $socket->fileno;
#   push(@SharedSockets, $socket);
    $SharedSockets{$socket->fileno()} = $socket;
    
#   print("[SharedSocket::ctor] fd: " . $self->{"socket_fd"} . "\n");
    
    return $self;
}

I understand that Perl wants to emulate the threads as heavy processes. When we create a thread, I guess it inherits all the file handles of the creator. If we would create a socket in a child, then neither the father nor its brothers would be aware, wouldn`t be? I wonder what were the initial motivations to introduce a such exotic thread model at the first place.

Again, I am getting the feeling I am trying to bend the language for something it was not supposed to perform... :oO

Kind regards,
s.fox

[BrowserUk]

Again, I am getting the feeling I am trying to bend the language for something it was not supposed to perform... :oO

No. You are simply trying to achieve your goal using techniques more suited to other languages.

Eg. In C, it is quite normal to process files one character at a time using something like this:

while ((c = getchar()) != EOF){
    ...
}

That is quite efficient in C; but doing the same thing in Perl (using getc()) is horribly inefficient; so you never see it done that way.

You appear to be wanting to use javaesque programming techniques in Perl; and then complain because they don't work the same way.

If you work with Perl and iThreads they can be very simple, efficient and effective. Work against them and you'll go away complaining that the tool is faulty ....