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
