|
From: Konstantin O. <kon...@my...> - 2004-10-20 22:05:55
|
* Guilhem Bichot <gu...@my...> [04/10/21 01:55]: > just curious why you don't do this all atexit(). is there any time where > someone would want to call mysql_server_init/end twice in a process? We could use atexit, but it's not that straightforward: - we will need to somehow ensure that our atexit handler is called last in the program (no other atexit function uses libmysqlclient) - afaiu this is not going to work for dynamic libraries, if a user unloads libmysqlclient.so by hand (by calling dlclose). Still this is maybe something we can implement, but I yet don't yet how we should deal with the two above problems. Having mysql_library_init() and mysql_library_end() is the safest solution for now. BTW, it'd be nice to know how other libraris deal with this problem. > >Well I had contacted Jonathan when I saw his post on > >valgrind-users. Your analysis is right. There are three things: > >1) a function to do this cleanup when the libmysqlclient library is not > >needed anymore by the program, exists, it's mysql_server_end(). > >2) but it's not documented in the right place in the manual, and I am > >in the process of fixing this, but delayed by 3) > >3) mysql_server_end() is a bad name for a function which just frees > >memory in the client; this function does nothing in the server. So we > >are right now (well, since 3 days - I mean, we didn't do only this > >over the last 3 days) discussing adding a more meaningful synonym like > >mysql_library_end() maybe. Historically it was called > >mysql_server_end() because it also frees memory if using libmysqld > >(the embedded version of MySQL, the MySQL server in a library). > > > >Calling mysql_server_end() fixed Jonathan's error. -- Konstantin Osipov, Software Developer MySQL AB, www.mysql.com |
|
From: Jonathan A. Z. <jon...@nu...> - 2004-10-20 22:12:19
|
The problem libdspam is running into with this is that we've had to add a configure option for whether or not to use this - if the third-party application uses mysql, our library can't call these functions. if it doesn't, we should - makes it rather difficult for redistribution. Perhaps if there were some way to at least tell if it was already initialized, then we would know whether or not to call it and end. Konstantin Osipov wrote: > * Guilhem Bichot <gu...@my...> [04/10/21 01:55]: > > >>just curious why you don't do this all atexit(). is there any time where >>someone would want to call mysql_server_init/end twice in a process? > > > We could use atexit, but it's not that straightforward: > - we will need to somehow ensure that our atexit handler is called > last in the program (no other atexit function uses libmysqlclient) > - afaiu this is not going to work for dynamic libraries, if a user unloads > libmysqlclient.so by hand (by calling dlclose). > > Still this is maybe something we can implement, but I yet don't yet how > we should deal with the two above problems. > Having mysql_library_init() and mysql_library_end() is the safest > solution for now. > BTW, it'd be nice to know how other libraris deal with this problem. > > >>>Well I had contacted Jonathan when I saw his post on >>>valgrind-users. Your analysis is right. There are three things: >>>1) a function to do this cleanup when the libmysqlclient library is not >>>needed anymore by the program, exists, it's mysql_server_end(). >>>2) but it's not documented in the right place in the manual, and I am >>>in the process of fixing this, but delayed by 3) >>>3) mysql_server_end() is a bad name for a function which just frees >>>memory in the client; this function does nothing in the server. So we >>>are right now (well, since 3 days - I mean, we didn't do only this >>>over the last 3 days) discussing adding a more meaningful synonym like >>>mysql_library_end() maybe. Historically it was called >>>mysql_server_end() because it also frees memory if using libmysqld >>>(the embedded version of MySQL, the MySQL server in a library). >>> >>>Calling mysql_server_end() fixed Jonathan's error. > > |
|
From: Konstantin O. <kon...@my...> - 2004-10-21 10:11:10
|
* Jonathan A. Zdziarski <jon...@nu...> [04/10/21 02:55]: > The problem libdspam is running into with this is that we've had to add > a configure option for whether or not to use this - if the third-party > application uses mysql, our library can't call these functions. if it > doesn't, we should - makes it rather difficult for redistribution. > > Perhaps if there were some way to at least tell if it was already > initialized, then we would know whether or not to call it and end. I don't see how it can help. You can't call mysql_library_end from within libdspam anyway: if a user tries to use anything but mysql_init/mysql_library_init in his application after you called mysql_library_end, he'll run into problems. Currently there is no way to find out if init was done, except that you can call it twice. If addition of this function can really help anywhere, me or Guilhem can discuss it with Monty. -- Konstantin Osipov, Software Developer MySQL AB, www.mysql.com |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2004-10-21 11:22:31
|
Hi, >>Perhaps if there were some way to at least tell if it was already >>initialized, then we would know whether or not to call it and end. > > > I don't see how it can help. You can't call mysql_library_end from within > libdspam anyway: if a user tries to use anything but > mysql_init/mysql_library_init in his application after you called > mysql_library_end, he'll run into problems. When using the GNU toolchain, if you implement _init and _fini functions, these will be called by the run-time linker when the library is loaded and unloaded. Most other platforms provide similar functionality as far as I know, but function names may differ. Actually I see now that _init and _fini are obsolete on GNU platforms, you have to use __attribute__((constructor)) and __attribute__((destructor)) instead. See for example: http://www.dwheeler.com/program-library/Program-Library-HOWTO/dl-libraries.html Also have a look at how GCC and other compilers handle initialization and destruction of static C++ objects on different platforms. See for example: http://www.codesourcery.com/cxx-abi/cxx-open.html#C1 Dimitri |
|
From: Jonathan A. Z. <jon...@nu...> - 2004-10-21 12:45:32
|
Yeah that's my point - most apps that link to libdspam won't be calling mysql at all, and will leave it all up to the storage driver interface in libdspam....so for that, we want to call init and end. For the occasional app that does, however, we don't want to...so some way of detecting if it's already been called would be very useful. Since it's supposed to be required (on paper at least), wouldn't it make sense to have the other functions fail unless it's called? Jonathan Konstantin Osipov wrote: > * Jonathan A. Zdziarski <jon...@nu...> [04/10/21 02:55]: > > >>The problem libdspam is running into with this is that we've had to add >>a configure option for whether or not to use this - if the third-party >>application uses mysql, our library can't call these functions. if it >>doesn't, we should - makes it rather difficult for redistribution. > > >>Perhaps if there were some way to at least tell if it was already >>initialized, then we would know whether or not to call it and end. > > > I don't see how it can help. You can't call mysql_library_end from within > libdspam anyway: if a user tries to use anything but > mysql_init/mysql_library_init in his application after you called > mysql_library_end, he'll run into problems. > > Currently there is no way to find out if init was done, except that you > can call it twice. If addition of this function can really help anywhere, > me or Guilhem can discuss it with Monty. > |