Ok. Let's fill the issue and clean-up sem_wait as well as I met that
code in sem_wait only, so other places should never return ECANCELED.
пт, 27 трав. 2022 р. о 17:07 Gregory Nutt пише:
>
> > Yes and no. I've posted a code from sem_wait that checks if a
> cancellation
> > is pending but cannot
Yes and no. I've posted a code from sem_wait that checks if a cancellation
is pending but cannot be performed due to the nesting level,
so enter_cancellation_point will just increment the nested count
and leave_cancellation_point will just decrement it. In this case ECANCELED
will be returned b
It was added by this commit
commit 9568600ab19ef7da61ae7de4b43f1fc075556102
Author: Gregory Nutt
Date: Wed Oct 4 15:22:27 2017 -0600
Squashed commit of the following:
This commit backs out most of commit
b4747286b19d3b15193b2a5e8a0fe48fa0a8638c. That change was added because
sem_
Yes and no. I've posted a code from sem_wait that checks if a cancellation
is pending but cannot be performed due to the nesting level,
so enter_cancellation_point will just increment the nested count
and leave_cancellation_point will just decrement it. In this case ECANCELED
will be returned by se
On 5/27/2022 12:52 AM, Petro Karashchenko wrote:
Hi,
Ok. That makes sense. But there is a strane code in sem_wait:
if (enter_cancellation_point())
{
#ifdef CONFIG_CANCELLATION_POINTS
/* If there is a pending cancellation, then do not perform
* the wait. Exit now with ECA
