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]

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

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