Re: pthread_mutexattr_setpshared ??
=> => 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. My $DAYJOB is working on an open source database/runtime system which has run with multiple processes and shared memory from day one, where day one was over 25 years ago. I introduced PSHARED mutexes/conditions to the software as an alternative to existing spin/yield/sleep locks, which are known to perform pretty badly in userland at scale. (I.e., large systems with tens of thousands of processes context switching themselves to death.) The PSHARED mutexes and the robust futex implementation underlying them provided some much needed stability at the top end. To be clear, I have no need to run this software on NetBSD, but I wanted to present a case where this facility can be used to solve Real World problems. Gary Duzan
Re: pthread_mutexattr_setpshared ??
On Mon, 16 Mar 2020 19:01:23 -0400 Greg Troxel 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.
pthread_mutexattr_setpshared ??
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.
and the kamailo code says:
* code to set PTHREAD_PROCESS_SHARED attribute for phtread mutex to cope
* with libssl 1.1+ thread-only mutex initialization
I am really unclear on this; it seems very strange to make a mutex
thread-local since the point is to interoperate aross threads, mostly.
But, this seems to be about a mutex working in one process, vs working
in a group of proceses when in common mapped memory.
In src/lib/libpthread, it seems that mutexattr shared attributes are
always PTHREAD_PROCESS_PRIVATE, and there is code to allow setting that
and throw an error on other values. But it's further ifdefed out.
kamailo has multiple ways to deal with mutexes, and maybe pthread isn't
the right answer on NetBSD.Or maybe the way openssl 1.1 behaves on
NetBSD means that they are process scope, and that's ok, and the
difficulty is only about sharing attributes somehow post fork.
Any clues appreciated -- perhaps this is just something
netbsd-{8,9,current} does not support.
