Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Aug 2010 05:15:39 +0000 (UTC)
From:      David Xu <davidxu@FreeBSD.org>
To:        cvs-src-old@freebsd.org
Subject:   cvs commit: src/lib/libthr/thread thr_cancel.c thr_cond.c thr_join.c thr_private.h thr_sig.c thr_syscalls.c
Message-ID:  <201008200515.o7K5FtIA055884@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
davidxu     2010-08-20 05:15:39 UTC

  FreeBSD src repository

  Modified files:
    lib/libthr/thread    thr_cancel.c thr_cond.c thr_join.c 
                         thr_private.h thr_sig.c thr_syscalls.c 
  Log:
  SVN rev 211524 on 2010-08-20 05:15:39Z by davidxu
  
    In current implementation, thread cancellation is done in signal handler,
  which does not know what is the state of interrupted system call, for
  example, open() system call opened a file and the thread is still cancelled,
  result is descriptor leak, there are other problems which can cause resource
  leak or undeterminable side effect when a thread is cancelled. However, this
  is no longer true in new implementation.
  
    In defering mode, a thread is canceled if cancellation request is pending and
  later the thread enters a cancellation point, otherwise, a later
  pthread_cancel() just causes SIGCANCEL to be sent to the target thread, and
  causes target thread to abort system call, userland code in libthr then checks
  cancellation state, and cancels the thread if needed. For example, the
  cancellation point open(), the thread may be canceled at start,
  but later, if it opened a file descriptor, it is not canceled, this avoids
  file handle leak. Another example is read(), a thread may be canceled at start
  of the function, but later, if it read some bytes from a socket, the thread
  is not canceled, the caller then can decide if it should still enable cancelling
  or disable it and continue reading data until it thinks it has read all
  bytes of a packet, and keeps a protocol stream in health state, if user ignores
  partly reading of a packet without disabling cancellation, then second iteration
  of read loop cause the thread to be cancelled.
  An exception is that the close() cancellation point always closes a file handle
  despite whether the thread is cancelled or not.
  
    The old mechanism is still kept, for a functions which is not so easily to
  fix a cancellation problem, the rough mechanism is used.
  
  Reviewed by: kib@
  
  Revision  Changes    Path
  1.17      +25 -21    src/lib/libthr/thread/thr_cancel.c
  1.26      +12 -2     src/lib/libthr/thread/thr_cond.c
  1.24      +7 -2      src/lib/libthr/thread/thr_join.c
  1.98      +2 -1      src/lib/libthr/thread/thr_private.h
  1.31      +64 -14    src/lib/libthr/thread/thr_sig.c
  1.24      +174 -59   src/lib/libthr/thread/thr_syscalls.c



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008200515.o7K5FtIA055884>