Re: lt_dlerror may cause potential issue in multi-thread environment

On 12/04/13 02:40, xiaonan wrote:
>  Hi, Nick:
>
>     Because lt_dlerror() function is not thread-safe, in the following 
> code:

Ok, I misunderstood your problem. I would say the solution is to wrap 
the calls with the mutext to force it into being thread safe. But you 
still run the risk if the driver does the same thing and not using the 
mutext so it will still have the same problem.
>
>     if ( !(connection -> dl_handle = odbc_dlopen( driver_lib )))
>     {
>         char txt[ 2048 ];
>
>         sprintf( txt, "Can't open lib '%s' : %s",
>                 driver_lib, lt_dlerror());
>
>         ......
>
>         return 0;
>     }
>
>     In multi-thread environment, the lt_dlerror() may return other 
> thread's error, or even NULL.
>
>     In your latest modif! ication:
>
>     if ( !(connection -> dl_handle = odbc_dlopen( driver_lib )))
>     {
>         char txt[ 2048 ];
>         const char *err;
>
>         err = lt_dlerror();
>
>         sprintf( txt, "Can't open lib '%s' : %s",
>                 driver_lib, err ? err : "NULL ERROR RETURN" );
>
>         ......
>         return 0;
>     }
>
>     This issue still exits.
>
>     Personally, I think the function of odbc_dlopen() can be modified 
> as this:
>
>     static void *odbc_dlopen( char *libname, cha! r *err );
>     {
>         ......
>         hand = lt_dlopen( libname );
>         if (hand)
>         {
>         }
>         else
>         {
>             sprintf(err, "%s", lt_dlerror());
>         }
>     }

Bit that still doesnt help. a context shift can happen between dlopen 
and dlerror so the error may relate to the other thread. If I understand 
correctly, all you have done is reduce the time between the dlopen and 
dlerror, its still not atomic.

-- 
Nick

_______________________________________________
unixODBC-dev mailing list
[email protected]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev