xiaoxiang781216 commented on code in PR #16030: URL: https://github.com/apache/nuttx/pull/16030#discussion_r2020723547
########## 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: > Yes, I think defining nxsem_xxx into libc is wrong also. What we should do is: > > * Move nxsem_xxx api back to kernel > * Implement a version of the sem_xxx APIs into libc that does not use cancelpoints / modify errno, like sem_wait_nocancel() or sem_wait_raw() that does the fast counter handling and system call into kernel if the fast counter cannot be used / the semaphore must block. > but sem_xxx need modify errno from POSIX. > Why do we need sem_wait_raw? Because many places in libc would benefit from the fast semaphore path, and it would be great if we had a set of APIs that implement this (like Jukka did with sem_wait_impl). > > Unfortunately this means that we must duplicate a bit of logic in libc/kernel (the fast counter handling needs to be duplicated) but as a benefit we get a much cleaner kernel/user separation. inline the implementation could avoid the duplication. -- 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
