in reply to Re: Thread-safe modules and callbacks
in thread Thread-safe modules and callbacks

Ok, lets see the client: 
my $MsgListener = new Msg::Server(2222,\&messageHandler);
$MSGListener->Start();

sub messageHandler{
        my $message = shift;
        my $peer = shift;
        chomp($message);
        print "MSG from $peer -> $message\n";
        my @tokens = split(' ',$message);
        my $token

}

[download]
The server just redirects messages to the callback and the callback gets executed on the message thread so we don't share variables unless we specifically share them, but we want to abstract the user from the threads, I'm not sure if it is possible at all.

Replies are listed 'Best First'.
Re^3: Thread-safe modules and callbacks
by BrowserUk (Patriarch) on May 10, 2008 at 01:04 UTC

    It depends upon what you're trying to achieve.

    1. If you just want the variables to be accessible by the handler using them, then using closures are the simplest option: 
      {
    my $n = 0;
    sub handler {
        my $tid = threads->self->tid;
        for( 1 .. 5e5 ) {
            usleep( 100 );
            print "$tid: ", $n++;
        }
    }
}

      [download]

      Each handler will get it's own copy of $n above and can use it without concerns for locking or sharing. It retains it's value across calls to the handler.

    2. If you need to share the data either between the handlers, or between each handler and the main thread, then that requires the data be shared. And that comes with the inherent need for locking.

      Isolating your users from the requirements of shared data is possible, but distinctly non-trivial.

      I am reluctant to expend energy describing possible approached until I:

      1. know that's what you want.
      2. impose upon you for a more complete description of the types of data and uses to which you envisage it will be put.
    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]
      It's the 2nd case
      Basically it's for a ipc through messages, in this case we'd have no-threaded process that uses the provided module. The module creates itself the thread and calls the callback for each message.
      Basically it'll just manage strings as messages are strings, the most common behaviour would be to add the messages to a queue(that must be shared with the rest of the process, this is part of the problem) but the user might do other operations on the callback that use external variables.
      So I really can't see a way of isolating the user from the thread system. We'd need to share every variable at the callback and every variable at the program(to be acesible from the callback) dymanically. I don't see the way, but just wondering....
      Thanks
[reply]
        So I really can't see a way of isolating the user from the thread system. We'd need to share every variable at the callback and every variable at the program(to be acesible from the callback) dymanically.

        You're saying that you want to share all user code variables with all the threads, but without the user being concerned with the fact that they are shared, nor even knowing that they are using threads at all. Sorry, but that simply isn't possible. Not with any technology I am aware of, and certainly not with Perl.

        That said, I think this is a genuine case of the notorious XY problem. That is, you are asking how to implement what you perceive is the solution to the problem, rather than describing the problem and asking how it might be solved.

        If you would start by posting a simple worked example of an application, from the user perspective, that talks to two servers (or clients) and demonstrates how you envisage them interacting, then an alternative solution may be apparent. Just describe the application, and how you would like the user visible API to e used to fulfill that application and forget about how it might be implemented. From that we'll see if we can't come up with something that could work for you.

        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]

In Section Seekers of Perl Wisdom