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

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:libdbi-users-
> [EMAIL PROTECTED] On Behalf Of Markus Hoenicka
> Sent: Thursday, May 15, 2008 10:22 AM
> To: Ethan Funk
> Cc: libdbi-users@lists.sourceforge.net
> Subject: [libdbi-users] PTHREAD_CANCEL_ASYNCHRONOUS safe?
> 
> Hi,
> 
> I have to admit that I'm not exactly familiar with this kind of
> stuff. Is there any documentation available about the
> requirements to call a code PTHREAD_CANCEL_ASYNCHRONOUS safe?
> 
> regards,
> Markus
> 
> Ethan Funk writes:
>  > Does any one know if  the dbi_conn_query function (and the
> underlying
>  > drivers) are PTHREAD_CANCEL_ASYNCHRONOUS safe?
>  > I would like to be able to cancel a query if it is taking too long.
>  >
>  > Ethan...
>  >
>  >
--------------------------------------------------------------------
> -----
>  > 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
> 
> --
> 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