Re: pthread_mutexattr_setpshared ??

[Sad Clouds <cryintothebluesky%gmail.com@localhost>]

On Mon, 16 Mar 2020 19:01:23 -0400
Greg Troxel <gdt%lexort.com@localhost> wrote:

> I am trying to build kamailo (sip) on NetBSD 8, and running into a
> pthread issue.
> 
> Kamailo uses pthread_mutexattr_setpshared.  This is documented in
> pthread_mutexattr(3), but at the bottom it says:
> 
>   BUGS
>        The pthread_mutexattr_getpshared() and
> pthread_mutexattr_setpshared() functions are hidden by default since
> only thread shared attributes are supported.

The way I read your email - it wants to use the mutex across different
processes i.e. PTHREAD_PROCESS_SHARED, but NetBSD only supports
PTHREAD_PROCESS_PRIVATE.

It explains it here why, since libssl now abstracts away and hides its
locking functions:
https://github.com/kamailio/kamailio/tree/master/src/modules/tls/utils/openssl_mutex_shared

No idea why they are sharing the same SSL context across multiple
processes, hence why they may need a mutex with PTHREAD_PROCESS_SHARED.

I've seen these issues before, usually this is down to a bad design.
People design multi-process subsystems, then they realise they need to
share data cross those processes and start using fcntl() for locking.
This of cause sucks because performance is horrible and fcntl() is
not aware of threads, so you get dreaded EDEADLK errors when in fact,
there is no deadlock at all. So the next stage becomes replacing
fcntl() with pthread mutex locks set to PTHREAD_PROCESS_SHARED. This is
still not ideal, because you have to deal with shared memory segments
and if one process exits while holding the lock, all other
threads/processes are now deadlocked. So then you need something like
a robust mutex lock, which NetBSD does not implement. So you get layers
of complexity just to deal with a bad design.

In summary, people should use simpler/better designs, i.e. single
process with multiple threads and that is it. No need to over-engineer
it.