On Wed, Apr 26, 2023 at 8:34 AM Ville Juven <ville.ju...@gmail.com> wrote:
> Hi, > > Thanks for pointing that out, basically the same issue I face. > > First I thought it would be simple to fix OR wrap around the usage of > SEM_INITIALIZER/NXSEM_INITIALIZER/NXMUTEX_INITIALIZER. My assumption was > that they are not used in very many places in user space. For wrapping > one option would be to do a lazy init of the semaphore when sem_wait() / > sem_post() / etc. are called and identify the non-init state by some > special flagging. > > However I'm totally wrong, PTHREAD_MUTEX_INITIALIZER exists as well and > this is used to initialize the semaphore in pthread_mutex_t and > pthread_cond_t. Trying to get rid of the initializer macro proves to be > too much re-factoring of code I'm not very familiar with (big risk > something will break) -> I'll try to figure out something else. PTHREAD_MUTEX_INITIALIZER not only exists, it's in the standard: https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_init.html Nathan
