Re: [libdbi-devel] Thread Safety question

[Artyom <art...@ya...>]

> > > For the record I had seen in sqlite (not sqlite3)
> backend usage of
> > > strtok. So it should be thread unsafe.
> 
> How does that make it thread-safe?

So it should be thread **un**safe.

-------------------------------------------
So... for the summary:

At this point:

On platforms where GNU extendtion timegm() exists the system is:
  1. Has not thread safe parts in;
     a. Loading/Unloading modules: dbi_initialize/dbi_shutdown
     b. Sqlite2 backend (and Sqlite3 in 8.2 and above)
  2. The rest is thread safe.

On MINGW it is not safe due to lack of strtok
(is it??????, may be it worth to add check as for timegm?)

At any platform this can easily be fixed to thread safe if
gmtime replaced with gmtime_r (can be checked using 
the patch attached above.

Am I right???

Artyom

----------------------------------------
--- configure.in-bck    2008-11-26 07:57:37.913799169 +0200
+++ configure.in        2008-11-26 07:59:58.815035118 +0200
@@ -135,6 +135,7 @@
 AC_REPLACE_FUNCS(atoll timegm)
 AC_CHECK_FUNCS(vasprintf)
 AC_REPLACE_FUNCS(asprintf)
+AC_CHECK_FUNCS(gmtime_r)

 dnl ==============================
 dnl Checks for header files
-----------------------------------------
--- timegm.c-bck        2008-11-26 07:57:53.373496023 +0200
+++ timegm.c    2008-11-26 08:01:43.612977664 +0200
@@ -30,7 +30,7 @@

 time_t timegm(struct tm *tm) {
   time_t temp_ltime;
-  struct tm *temp_gm;
+  struct tm temp_gm;

   if (!tm) {
     temp_ltime = 0;
@@ -39,9 +39,13 @@
     temp_ltime = mktime(tm);
   }

-  temp_gm = gmtime(&temp_ltime);
+  #ifdef HAVE_TIMEGM_R
+    gmtime_r(&temp_ltime,&temp_gm);
+  #else
+    temp_gm = *gmtime(&temp_ltime);
+  #endif

-  return (time_t)(temp_ltime + (temp_ltime - mktime(temp_gm)));
+  return (time_t)(temp_ltime + (temp_ltime - mktime(&temp_gm)));
 }

 #endif /* HAVE_TIMEGM */
-------------------------------------------