Re: [libdbi-devel] Thread Safety question

[Florian F. <oc...@ve...>]

Hi,

On Tue, Nov 25, 2008 at 11:57:07AM +0100, Markus Hoenicka wrote:
> > gmtime_r, readdir_r exists on both Linux and Cygwin platforms and
> > according to man mages exists in FreeBSD as well:
> 
> Yes, I've mentioned those as I do have access to them and positively
> know they support the reentrant versions. I'm more concerned about the
> systems that I don't run myself, like OSX, the other *BSDs, Solaris
> and so on.

since all XSI compliant systems are required to provide thread- and
reentrant-safe functions, those functions are fortunately available on
the vast majority of systems.

So if you compile with
 CPPFLAGS="-D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=500 -D_REENTRANT -D_THREAD_SAFE"
you should get the XS-interface on all noted platforms, as far as I
know.

Of course, there are the occasional oddities here and there, as with all
``modern'' interfaces. For example, under Solaris, if you don't specify
the above flags, you need to at least specify
 CPPFLAGS="-D_POSIX_PTHREAD_SEMANTICS"
to get the standard-conforming versions of some functions, such as
`strtok_r'.

> > However readdir_r is less important because it is quite reasonable
> > to load shared objects from single thread.
> >
> 
> Once again, it is reasonable, but we must not rely on users doing only
> things that we assume as reasonable.

Agreed. I use libdbi for a plugin to collectd[0]. Each plugin is called
from a thread-pool, so using functions with static memory is an absolute
no-go. Especially since it's not that big of a deal, really. In my
experience, switching from `strerror' to `strerror_r' is the biggest
deal, because it's often used in lots of places.

> > Is there other points where non reenterable functions are used?
> 
> To the best of my knowledge, not in libdbi.

I didn't find any more thread-unsafe functions with a really quick
check:
  octo@leeloo:~/libdbi $ egrep -riI '\<(asctime|ctermid|ctime|getgrgid|getgrnam|getlogin|getpwnam|getpwuid|gmtime|localtime|rand|readdir|srand|strerror|strtok|tmpnam|ttyname)\>' drivers/
  octo@leeloo:~/libdbi $
Dunno if that's all thread-unsafe functions, but it's better than
nothing ;)

> This is a good excuse to make libdbi thread-safe :-)

Please consider the attached patch. It's against what I considered to be
the current CVS revision, but I haven't CVS for quite some time, so
please forgive me if I'm a bit off ;)

I did not remove that ugly `strtok == strtok_r' hack in
src/dbi_result.c, but I added a warning to it. Is that really necessary?

> > 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?

Regards,
-octo

[0] <http://collectd.org/>
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/