> Date: Wed, 19 Mar 2014 18:40:14 -0400 > From: Ted Unangst <[email protected]> > > Don't worry pshared semaphore fans, I haven't forgotten about you. > > In order to support pshared semaphores, as opposed to global > sem_open semaphores, we need to allow calling programs to allocate the > necessary structures. Currently, librthread hides nearly all > implementation details by exporting only pointer types. > > There are a few problems with just pushing the structure definitions > out into the header. > > 0. It's ugly. > 1. Every future implementation change results in a major library > change. > 2. Testing changes and rolling them back becomes a serious burden. > > If we're going to do this, I think we need to do it the right way. > > 1. Export opaque storage types, as in > typedef struct _sem_storage { > char payload[64]; > } sem_t; > Then librthread will be able to add and shuffle fields inside the > struct as necessary. > > 2. Do it for all (or most) or most of the types. mutex is the obvious > one. > > This is a major flag day for librthread. All the various scripting > modules for python/ruby/perl/lua/etc that require LD_PRELOAD are going > to implode vigorously. Most of the ruby gems I have installed weren't > installed through pkg_add, making this even more of a landmine. > Changing structure sizes goes wrong in far worse ways than adding or > removing symbols. > > It would have been nice to ride along the 5.5 time_t reinstall > everything bump, but we missed it. Even so, I think we can only afford > to do this once, and not drag it out in a serious of increments in > which people get burned over and over. > > The other solution is to stick with the status quo. pshared semaphores > are the only missing feature that's popped up on my rader. pshared > mutexes have not. And semaphores can be fairly easily switched to > using sem_open. If there are ports that require pshared support, I'd > be happy to help patch them to use sem_open.
Xorg now uses pshared mutexes and condition variables to implement the "fences" that are used in the new present extension. That extension is optional, and for now we can probably get away with not implementing it. But it does show that the pshared stuff isn't completely academic. I think we should go the opaque storage route, and make sure we allocate enoughspare space that we don't need to enlarge the structures anytime soon.
