Andreas Ericsson <a...@op5.se>: > That's basically how the _r suffix works. Take a look at rand() and > rand_r(). If the function does something requiring state the thread > safe version of it will require that state to be passed as a variable, > exactly like the instance pointer used for libdbi. >
Maybe I'm a bit over-cautious, but I'd like to avoid the impression that using the _i/_r functions will allow to build thread-safe applications out of the box. We still have a problem with our error messages, as these share one buffer per connections. Applications that share connections between threads easily run into problems here. However, if you argue that no one expects _r functions to imply thread-safety, I'll be happy to revert the change. What do others think? regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ libdbi-devel mailing list libdbi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-devel
