Re: [SPAM] - [c++-pthreads] Re: [SPAM] - [c++-pthreads] Re: [SPAM] - FW: RE: [c++-pthreads] Re: I'm Lost - Email found in subject - Email found in subject - Email found in subject

[Ted Baker <baker@xxxxxxxxxx>]

On Wed, Jul 27, 2005 at 10:17:10PM +0200, Alexander Terekhov wrote:
> 
> Ted Baker wrote:
> [...]
> > receives a a signal and the signal is succesfully handled.  IFAIK,
> > every blocking call that POSIX guarantees will be interrupted by
> > pthread_cancel can also be interrupted by signals.
> 
> "The pthread_join() function shall not return an error code of 
>  [EINTR]."

Interesting...  I should have remembered this, having implemented
it once, about 15 years ago.  I had forgotten how many places
Pthreads calls broke the traditional POSIX signal model.

> And I can go on and on (including stuff like "may fail" vs "shall 
> fail" on semas, etc.),

Yes, POSIX allows implementations to not interrupt certain (as I
recall, most) of the blocking calls, via this "may" language.  On
the other hand, if the system does not allow them to be
interrupted a Pthread library is going to have difficulty
implementing a useful (unblocking) thread cancellation point at
those calls.

> but I'll just let you check it yourself by 
> clicking on every "shall occur" cancellation point here:
> 
> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html#tag_02_09_05_02

--Ted