jlaitine commented on code in PR #16030: URL: https://github.com/apache/nuttx/pull/16030#discussion_r2019736741
########## libs/libc/semaphore/sem_wait.c: ########## @@ -98,3 +98,43 @@ int sem_wait(FAR sem_t *sem) leave_cancellation_point(); return ERROR; } + +/**************************************************************************** + * Name: nxsem_wait + * + * Description: + * This function attempts to lock the semaphore referenced by 'sem'. If + * the semaphore value is (<=) zero, then the calling task will not return + * until it successfully acquires the lock. + * + * This is an internal OS interface. It is functionally equivalent to + * sem_wait except that: + * + * - It is not a cancellation point, and + * - It does not modify the errno value. + * + * Input Parameters: + * sem - Semaphore descriptor. + * + * Returned Value: + * This is an internal OS interface and should not be used by applications. + * It follows the NuttX internal error return policy: Zero (OK) is + * returned on success. A negated errno value is returned on failure. + * Possible returned errors: + * + * - EINVAL: Invalid attempt to get the semaphore + * - EINTR: The wait was interrupted by the receipt of a signal. + * + ****************************************************************************/ + +#if !defined(CONFIG_BUILD_FLAT) && !defined(__KERNEL__) +int nxsem_wait(FAR sem_t *sem) Review Comment: I also find it cleaner to have separate functions in libc and kernel. Still we'll need the version in libc which is not a cancellation point for internal usage in libc. I don't like at all what has been done with e.g. bringing nxmutex semantics into libc. The previous version of this PR was kind of ok for me as long as it is clearly said that nxsem is an internal os interface and usage stays in within libc. Libc internals are nuttx internal usage to me. An alternative would be making a separate functions sem_xxx_nocancel, and replace all nxsem_xxx in libc, feels maybe a bit unnecessary hassle? This version works and is what Xiao demanded, if I understood correctly. The ifdef __KERNEL__ decorations are there for protected build compilation. Let's continue the discussion and find a structure which is ok for all! Could you @pussuw suggest an alternative naming / structure? I am ok with working on this. But let's try to find concensus first, as it may take several hours to just modify the structure/naming and make it pass CI again, aven if I didn't change the functionality at all; actually none of the variants during last week changed the functionality.... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
