Thanks. That was exactly the sort of information I was looking for, and the answer I expected. I did have to ask. Rainer's explanation of PTHREAD_CANCEL_ASYNCHRONOUS safeness was very good - thanks!
This may be a suggestion more for the libdbi_driver folks, but it sure would be nice if I could set a Timeout property for connection settings on the postgress and mysql drivers. The SQLite drivers have this. Thanks everyone. Ethan... On May 15, 2008, at 5:41 AM, Markus Hoenicka wrote: > Hi, > > thanks for the excellent explanation. With that in mind, I'd say it > depends. libdbi does not use mutexes. Also, the libdbi library does > not allocate any memory *before* the database client query function > returns. However, some client libraries require the allocation of > memory before the query can performed (e.g. firebird), so these > drivers will have allocated some memory in case you cancel a > query. Everything else is beyond the control of > libdbi/libdbi-drivers. If the query implementation of one of the > supported client libraries uses mutexes or allocates memory which is > not freed if you cancel a query, you'll experience the same problems > as if you didn't use libdbi as an abstraction layer. It is probably > advisable to ask the lists of the database engines you plan to support > if their clients safely handle cancelling queries. > > regards, > Markus > > Rainer Gerhards writes: >> Well, the base requirement is that you need to make sure no >> resource is >> left after you are cancelled. Let's say you lock a mutex (A), than do >> some work (B), and later unlock the mutex (C). Then you get cancelled >> during B). In that case the mutex will remain locked if you do not >> explicitly unlock it. That, of course, will cause trouble when you >> come >> back the next time - you'll then block on A) because the mutex is >> still >> locked. >> >> Less severe problems occur if you malloc() in A and free() in C). >> If you >> are cancelled in B, the result is a mem leak. >> >> To prevent these situations, you can either block cancellation >> before A >> and enable it again after C or you can work with so-called cancel >> cleanup handlers, which in essence do what you would do in C. >> >> The bottom line is that an app must be aware of cancellation. I'd >> personally find this a bit dangerous, given the third party nature of >> libdbi. IMHO the best option would be the caller handle the >> complexity. >> At least this is what I am doing in rsyslog (but, granted, >> cancellation >> happens very infrequently there, so I may be overlooking something >> obvious). >> >> HTH, >> Rainer > > -- > Markus Hoenicka > [EMAIL PROTECTED] > (Spam-protected email: replace the quadrupeds with "mhoenicka") > http://www.mhoenicka.de > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > libdbi-users mailing list > libdbi-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libdbi-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
