Sinisa,

On Mon, 15 Jan 2001, Sinisa Milivojevic wrote:

> Hi!
> 
> 
> I will answer questions one by one.
> 
> 
> 1) thread safe client library only has mutexes around thread sensitive
> code. They have nothing to do with timeouts. Timeouts can be resolved
> with corresponding startup variables

got it.

> 
> 2) If you use separate MYSQL structures for each thread, then you have
> no limitations what so ever.
> 
> 3) If you use separate structures / pointers, you do not have to put
> mutex locks
> 

My process has three threads and three different MYSQL structures.
I have found that if I don't let the three mysql_real_connect() calls go
one by one when I spawn the daemon, and then wait in each thread for them
all to finish, I get an error that my query was interrupted, or that I am
attempting to run commands out of sync.

This is the code I'm using to make the connections (I have this same code 
in three different source files for three different threads):

        pthread_mutex_lock(&num_connected_mutex);
        if(!db_connect(dbm)) {
                fprintf(stderr, "Error on db_connect(): %s\n",
                        db_error(dbm));
                clean_die(1);
        }
        printf("main.cc: %d\n", num_connected+1);
        if (++num_connected==3)
                pthread_cond_broadcast(&all_connected_cond);
        else pthread_cond_wait(&all_connected_cond, &num_connected_mutex);
        pthread_mutex_unlock(&num_connected_mutex);


I have also recently been running into errors with mysql_get_row returning
errors (Commands out of sync; You can't run this command now), and when I
insert the line:

if (fork()) wait(NULL);

just after the above code, the problem goes away.  This leads me to
believe that the problem is related to thread safety, but I'm not sure.

Oh!  It has just occured to me that one potential complication is that I
have an unusual system of database wrappers.  The calls above like 
db_connect, db_error, etc. are just wrappers for the mysql calls, except
that I have a system of extensible database implementation modules, so the
process itself is not actually linked to libmysqlclient_r, it dlopen()'s a
shared library which is linked to the mysql client lib, and then defines
the various database calls.  Could this be causing my problems?  Maybe I
need to only load this module in one thread.  Should it make any
difference?

Thanks for all your help.

Kyle

<[EMAIL PROTECTED]>

> 4) I still think it is better to use local static MySQL++ objects then
> global, but this is impolementation specific.
> 
> 
> Regards,
> 
> Sinisa
> 
>       ____  __     _____   _____  ___     ==  MySQL AB
>      /*/\*\/\*\   /*/ \*\ /*/ \*\ |*|     Sinisa Milivojevic
>     /*/ /*/ /*/   \*\_   |*|   |*||*|     mailto:[EMAIL PROTECTED]
>    /*/ /*/ /*/\*\/*/  \*\|*|   |*||*|     Larnaka, Cyprus
>   /*/     /*/  /*/\*\_/*/ \*\_/*/ |*|____
>   ^^^^^^^^^^^^/*/^^^^^^^^^^^\*\^^^^^^^^^^^
>              /*/             \*\                Developers Team
> 



---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to