Re^4: mysqlPP has no driver CLONE() function so is unsafe threaded

Well, its kinda solved... However, this means that I cant have a "global" db connection? What about this situation:

my $dbh = DBI->connect("dbi:mysql:$db:$host", "$db_user", "$db_passwor
+d", {RaiseError => 0, PrintError => 0} ) # We do the error check. May
+be we dont wanna die if error!
                               or errTrap("Cannot connect to the datab
+ase");


threads->create(&dbUpdate()))->join;
threads->create(&anotherThread()))->join;

sub dbUpdate() {

    while(1) {
         do som db stuff when wanted
    }
}

sub anotherThread() {

   do stuff on shared variables that the db uses...

}
[download]

Guess the solution is to have the db obj in the dbUpdate function ONLY...

Comment on Re^4: mysqlPP has no driver CLONE() function so is unsafe threaded Download Code

Replies are listed 'Best First'.
Re^5: mysqlPP has no driver CLONE() function so is unsafe threaded by BrowserUk (Patriarch) on Aug 03, 2005 at 05:02 UTC
However, this means that I cant have a "global" db connection? Correct. But this is not a restriction of Perl, or Perl's threads. The restriction lies within the DB vendor's libraries. It's fundemental design requirement with threaded architectures, that APIs should be reentrant, but code that has been ported to threads from a pre-threaded environment frequently takes shortcuts to avoid too much change to legacy code. Often pre-threaded APIs simply do not lend themselves to reentrancy. The classic example of this is the C function strtok(), which modifies it's argument, retains a library allocated pointer to the next argument, and forgets what delimiter it is using between successive calls. Long deprecated, but still a part of most C-libraries, it was never safe to use, but still is. There are many more hidden gotchas like it. Guess the solution is to have the db obj in the dbUpdate function ONLY ... The biggest problem with your design as posted is that you show no indication of how you are going to indicate to the db thread when the other thread is finished modifying the shared variables. Ie. Even when you move `$dbh = DBI->connect( ... )` inside the db thread, you still have to think about the fact that you do not control when your threads run, or when they get interupted. I appreciate that you are only posting snippets to give a flavour of what you are doing and that you may well have thought about much more than you are showing, but `while(1){` is an endless loop that does not bode well. If you have a high level pseudo-code description of your application, or even a wordful description of what you hope to achieve by using threads, it would be easier to advise you. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: mysqlPP has no driver CLONE() function so is unsafe threaded
by BrowserUk (Patriarch) on Aug 03, 2005 at 05:02 UTC

However, this means that I cant have a "global" db connection?

Correct. But this is not a restriction of Perl, or Perl's threads. The restriction lies within the DB vendor's libraries.

It's fundemental design requirement with threaded architectures, that APIs should be reentrant, but code that has been ported to threads from a pre-threaded environment frequently takes shortcuts to avoid too much change to legacy code. Often pre-threaded APIs simply do not lend themselves to reentrancy.

The classic example of this is the C function strtok(), which modifies it's argument, retains a library allocated pointer to the next argument, and forgets what delimiter it is using between successive calls. Long deprecated, but still a part of most C-libraries, it was never safe to use, but still is. There are many more hidden gotchas like it.

Guess the solution is to have the db obj in the dbUpdate function ONLY ...

The biggest problem with your design as posted is that you show no indication of how you are going to indicate to the db thread when the other thread is finished modifying the shared variables.

Ie. Even when you move $dbh = DBI->connect( ... ) inside the db thread, you still have to think about the fact that you do not control when your threads run, or when they get interupted.

I appreciate that you are only posting snippets to give a flavour of what you are doing and that you may well have thought about much more than you are showing, but while(1){ is an endless loop that does not bode well. If you have a high level pseudo-code description of your application, or even a wordful description of what you hope to achieve by using threads, it would be easier to advise you.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

[reply]
[d/l]
[select]