u7k4rs6 commented on issue #20407: URL: https://github.com/apache/nuttx/issues/20407#issuecomment-6265703519
I dug into this a bit on current master to help pick a direction. The C initializer isn't zero. It sets `mholder = NXSEM_NO_MHOLDER` and `flags = SEM_TYPE_MUTEX`, and where those land depends on the config: offset 16 on sim:nsh (64-bit), 0 with `CONFIG_PTHREAD_MUTEX_UNSAFE`, and 8 on 32-bit. So a single constant on the Rust side can't be right everywhere. A zeroed mutex doesn't work either. On sim, `pthread_mutex_trylock()` on a never-locked mutex that was memset to 0 returns `EBUSY`, so locking it would just hang. `PTHREAD_RWLOCK_INITIALIZER` has the same problem since it embeds the mutex. The cond initializer really is all zeros, so that one's fine. `std::sync::Mutex` isn't affected today because std always calls `pthread_mutex_init()` after using the constant. Only code that uses `libc::PTHREAD_MUTEX_INITIALIZER` directly is hit, like statics and FFI. That also means removing it from libc would need a change in std too, since the unix mutex refers to it. I think the cleanest fix is on the NuttX side: make an all-zero `pthread_mutex_t` valid like on glibc/musl, e.g. the pthread mutex code lazily initializing one when `sem.flags == 0`. That touches the lock path though, so I'd like to hear what you think before sending a patch. Happy to do the libc/std side instead if you'd rather go that way. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
