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

Reply via email to