Serge Yuschenko <email@example.com> wrote in message
“David Gibbs” <> firstname.lastname@example.org> > wrote in message
news:aq6v5g$rn4$> email@example.com> …
Serge Yuschenko <> firstname.lastname@example.org> > wrote:
I’m a little bit confused by the “Library Reference”. In the
the ThreadCancel() it is said: “All kernel calls that block are
points, with the exception of MsgSendvnc() and SyncMutexLock()”. So it
that MsgReceive*() family functions are cancellation points. It is
prove with a simple test. It is perfectly normal. Otherwise how would
possible to cancel a thread waiting for a message. What puzzling me is
MsgReceive*() functions are not included in the list of cancellation
and in safety table for those functions “Cancellation Point” is set to
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
cancellation point and it is not in the list. What I’m afraid of that
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
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
that calls a blocking kernel call that’s a cancellation point will
become a cancellation point when the kernel call is made”, but
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
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).