Re: For review: pthread_setcancelstate.3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Michael,

Looks good to me.

Loïc.
--

Hi Loic,

On Mon, Nov 24, 2008 at 3:56 PM, Loic Domaigne <tech@xxxxxxxxxxxx> wrote:
Gidday Michael,


The paragraph is important, but I found it somewhat difficult to read.
Yes, I see.  There was at least one clumsy wording "Since...since"
which made that over-long sentence had to parse.
[...]

Thanks Loic.  I took some pieces of your suggestion, and arrived at
the following

      Setting  the  cancelability type to PTHREAD_CANCEL_ASYNCHRONOUS
      is rarely useful.  Since the thread could be  canceled  at  any
      time, it cannot safely reserve resources (e.g., allocating mem-
      ory with malloc(3)), acquire mutexes, semaphores, or locks, and
      so  on.   Reserving  resources is unafe because the application
s/unafe/unsafe/

Fixed.

      has no way of knowing what the state of these resources is when
      the  thread is canceled; that is, did cancellation occur before
      the resources were reserved, while they were reserved, or after
      they  were  released?  Consequently, clean-up handlers cease to
worse: the invariant of some internal structures might get violated (e.g. if
a list is used to manage chunk of memory malloc'ed, and the thread gets
asynchronously canceled while updating the list).

Yes, maybe it's worth emphasizing that.  I added a sentence, so now we have:

       Setting  the  cancelability type to PTHREAD_CANCEL_ASYNCHRONOUS
       is rarely useful.  Since the thread could be  canceled  at  any
       time, it cannot safely reserve resources (e.g., allocating mem-
       ory with malloc(3)), acquire mutexes, semaphores, or locks, and
       so  on.   Reserving resources is unsafe because the application
       has no way of knowing what the state of these resources is when
       the  thread is canceled; that is, did cancellation occur before
       the resources were reserved, while they were reserved, or after
       they were released?  Furthermore, some internal data structures
       (e.g., the linked list of free blocks managed by the  malloc(3)
       family  of  functions)  may be left in an inconsistent state if
       cancellation occurs in the middle of the function call.  Conse-
       quently,  clean-up handlers cease to be useful.  Functions that
       can be safely asynchronously canceled are called  async-cancel-
       safe  functions.   POSIX.1-2001 only requires that pthread_can-
       cel(3), pthread_setcancelstate(),  and  pthread_setcanceltype()
       be  async-cancel-safe.   In  general,  other  library functions
       can't  be  safely  called  from  an  asynchronously  cancelable
       thread.   One  of  the  few circumstances in which asynchronous
       cancelability is useful is for cancellation of a thread that is
       in a pure compute-bound loop.

Thanks Loic.

Cheers,

Michael


--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux