[c++-pthreads] C++ and posix threads

[Alexander Terekhov]

Nathan Myers wrote:
[...]
> This is the second time you have asked this.  I haven't noticed
> anybody on this list suggesting read() should throw an exception.

read(), fread(), printf() and etc. all should throw an exception.

http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_09.html#tag_02_09_05_02

"The side effects of acting upon a cancellation request while 
 suspended during a call of a function are the same as the side 
 effects that may be seen in a single-threaded program when a 
 call to a function is interrupted by a signal and the given 
 function returns [EINTR]. Any such side effects occur before 
 any cancellation cleanup handlers are called.

 Whenever a thread has cancelability enabled and a cancellation 
 request has been made with that thread as the target, and the 
 thread then calls any function that is a cancellation point 
 (such as pthread_testcancel() or read()), the cancellation 
 request shall be acted upon before the function returns. If a 
 thread has cancelability enabled and a cancellation request is 
 made with the thread as a target while the thread is suspended 
 at a cancellation point, the thread shall be awakened and the 
 cancellation request shall be acted upon. However, if the 
 thread is suspended at a cancellation point and the event for 
 which it is waiting occurs before the cancellation request is 
 acted upon, it is unspecified whether the cancellation request 
 is acted upon or whether the cancellation request remains 
 pending and the thread resumes normal execution."

http://google.com/groups?selm=hUFm8.1374%24fL6.26921%40news.cpqcorp.net

"The second list is of OPTIONAL cancellation points. The 
 distinction is, roughly, between what are conventionally 
 syscalls into the kernel (required) vs what are conventionally 
 user-space C runtime functions that MIGHT use those syscalls. 
 The intent was that library calls which might use the syscalls 
 be allowed to check for cancellation only when they actually 
 make the kernel calls; e.g., when printf() flushes its buffer 
 by calling write(). In practice, the optional list is more 
 often used as an excuse to avoid recoding the library to deal 
 with cancellation, instead disabling it around the syscall. 
 This is all quite convenient for implementations, of course, 
 but bad for applications. All applications that use any of 
 these functions must be prepared to react correctly should 
 cancellation occur at any such call... but at the same time 
 may not portably DEPEND on cancellation occurring.

 [...]

 Nevertheless, the standard should specify mechanism, not 
 policy. To say "thou shalt not catch cancel because I don't 
 think you should" is mandating the committee's collective 
 consensus of "proper behavior", and that's at best 
 inappropriate. There are always "exceptions". If some 
 standard application really does need to catch and finalize 
 "all exceptions", there's absolutely no justification for 
 making cancel or thread exit any different from all the 
 others. They SHOULD be in the std::exception hierarchy, 
 though perhaps in a separate "thread" subclass hierarchy."

regards,
alexander.