Re: [Quickfix-developers] Usage of non-threadsafe C functions in QF
Brought to you by:
orenmnero
Menu
▾
▴
Re: [Quickfix-developers] Usage of non-threadsafe C functions in QF
|
From: <OM...@th...> - 2003-04-03 09:26:13
|
It appears under windows they are not thread safe. From MSDN: "gmtime, mktime, and localtime all use a single statically allocated tm= structure for the conversion. Each call to one of these routines destro= ys the result of the previous call." In fact it seems that if I am reading that correctly, all three methods= share the same static structure. I'd prefer not to lock (long term) because this is a frequently called method, and would add some unwanted contention. What might have to be = done in the future is to start using the Win32 API equivalents instead. This looks like an important fix so it should probably go out with 1.4.= 1, initially using locking for windows. --oren |---------+-----------------------------------------------> | | Joerg Thoennes | | | <Joe...@ma...> | | | Sent by: | | | qui...@li...| | | ceforge.net | | | | | | | | | 04/03/2003 02:47 AM | | | Please respond to Joerg.Thoennes | | | | |---------+-----------------------------------------------> >--------------------------------------------------------------------= --------------------------| | = | | To: developers QuickFIX <qui...@li...= ceforge.net> | | cc: = | | Subject: [Quickfix-developers] Usage of non-threadsafe C fun= ctions in QF | >--------------------------------------------------------------------= --------------------------| Hi, inspired by Barry Bishops core dumps on a fast multiprocessor Solaris machine, I just checked if QF used functions which have re-entrant equivalents on Solaris or Li= nux (suffixed by _r). Here is what I found: ./include/FieldTypes.h: *static_cast < tm* > ( this ) =3D *gmtime( &= sec ); ./include/FieldTypes.h: *static_cast < tm* > ( this ) =3D *localtime= ( &time ); ./include/FieldTypes.h: *static_cast < tm* > ( this ) =3D *gmtime( &= t ); ./src/C++/FieldTypes.h: *static_cast < tm* > ( this ) =3D *gmtime( &= sec ); ./src/C++/FieldTypes.h: *static_cast < tm* > ( this ) =3D *localtime= ( &time ); ./src/C++/FieldTypes.h: *static_cast < tm* > ( this ) =3D *gmtime( &= t ); ./src/C++/Utility.cpp: buf =3D gethostbyname( name ); ./src/C++/Utility.cpp: return inet_ntoa( **paddr ); The last function probably does not count, since the man page states th= at the returned buffer is in a thread local data space (and the _r variant is not mentioned in= the man pages). BUT: The other function can really account for some core dumps. Actuall= y we used all these function in our software until some release consistently core dumped on= our fast multiprocessor production machine. As a quick fix we used the pbind command to assign = only one processor to the process. Analysis of the core file revealed the culprits listed abo= ve. After replacing the usage of gmtime(), localtime() and gethostbyname() by their _r variants= , core dumping stopped and all went fine since then. Oren, I have no way to check whether the functions on Windows are threa= d safe by default. But I would suggest to put these functions also into Utility.cpp and perhaps protect the Windows variants by a mutex if they are unsafe. If you need an example for the UNIX implementation, I could extract one out of our code. Cheers, J=F6rg -- Joerg Thoennes http://macd.com Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers = |
