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
