Re^3: Thread-safe modules and callbacks

It depends upon what you're trying to achieve.

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.
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."

Comment on Re^3: Thread-safe modules and callbacks Select or Download Code

Replies are listed 'Best First'.
Re^4: Thread-safe modules and callbacks by Saladino (Beadle) on May 10, 2008 at 09:53 UTC
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]
Re^5: Thread-safe modules and callbacks by BrowserUk (Patriarch) on May 10, 2008 at 13:52 UTC
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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^6: Thread-safe modules and callbacks by Saladino (Beadle) on May 10, 2008 at 14:25 UTC
Ok, here is the way it works at this moment. `#!/usr/bin/perl use strict; use warnings; use Server; my $Listener = new Server(2222,\&messageHandler); $Listener->Start(); my @messages; push(@messages,"something"); sub messageHandler{ my $message = shift; my $peer = shift; chomp($message); push(@messages,$message); print "Inside callback @messages\n"; } while(1){ print "Outside callback @messages\n"; sleep(1); }` [download] Start sending messages saladino@Zack$ perl pgenerator.pl Listening Outside callback something Outside callback something Outside callback something Outside callback something Outside callback something Outside callback something Outside callback something Outside callback something Outside callback something Inside callback sdfas Outside callback something Inside callback sdfas safsadf Outside callback something Outside callback something Inside callback sdfas safsadf sadfsasafsa Outside callback something Outside callback something Outside callback something [download] If i share @messages, it would work, but that doesn't abstract the client from threads	[reply] [d/l] [select]
Re^7: Thread-safe modules and callbacks by BrowserUk (Patriarch) on May 10, 2008 at 15:03 UTC
Re^8: Thread-safe modules and callbacks by Saladino (Beadle) on May 10, 2008 at 15:13 UTC
Some notes below your chosen depth have not been shown here