Serge Yuschenko <serge.yuschenko@rogers.com> wrote in message
news:aq7crm$por$1@inn.qnx.com…
“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:aq6v5g$rn4$> 2@nntp.qnx.com> …
Serge Yuschenko <> serge.yuschenko@rogers.com> > wrote:
Hi,
I’m a little bit confused by the “Library Reference”. In the
description
of
the ThreadCancel() it is said: “All kernel calls that block are
cancellation
points, with the exception of MsgSendvnc() and SyncMutexLock()”. So it
means
that MsgReceive*() family functions are cancellation points. It is
easy
to
prove with a simple test. It is perfectly normal. Otherwise how would
it
be
possible to cancel a thread waiting for a message. What puzzling me is
that
MsgReceive*() functions are not included in the list of cancellation
points
and in safety table for those functions “Cancellation Point” is set to
“No”.
Not sure about MsgReceive().
Hi David. What are you not sure of ? > 
> That MsgReceive() is not in that
list or that it is cancellation point? I can assure you in both. It works
as
cancellation point and it is not in the list. What I’m afraid of that
maybe
there is a reason why it is not in the list. Maybe it works as a
cancellation point under certain circumstances only, or its not going to
be
such in the next release. Something like this.
I think, MsgReceive() COULD non-blocking (if there is already a
message on the channel). In this case, it goes into kernel, copy the message
(from sender), and come out of the kernel right away. In this path, it won’t
be a cancellation point.
In the same ThreadCancel() description also mentioned that “any
function
that calls a blocking kernel call that’s a cancellation point will
itself
become a cancellation point when the kernel call is made”, but
select() that
calls MsgSend() is not in the cancellation point list again.
It could call MsgSendnc().
It is very unlikely. At first, I saw MsgSend() call in the _select_event()
function some time ago. I believe that things could get changed since that
time, but select() still does work as cancellation point without a
problem.
My main concern is that if select() is not recommended to be used as
cancellation points (it would be very interesting to know why) what
alternative do I have to cancel a thread hanging on select()?
Hm, I don’t have reason for this one. select() works with MsgSend()
and (usually replyed immediatly), and blocked into SignalWaitInfo()
(which is still a cancellation point).
-xtang