> From: "Ted Unangst" <t...@tedunangst.com>
> Date: Thu, 09 Jul 2020 11:07:02 -0400
>
> On 2020-07-08, Mark Kettenis wrote:
> > > From: "Ted Unangst" <t...@tedunangst.com>
> > > Date: Wed, 08 Jul 2020 05:20:23 -0400
> > >
> > > On 2020-07-08, Ted Unangst wrote:
> > > > I think this makes sem_init(pshared) work.
> > >
> > > Whoops, need more context to include the header file changes.
> >
> > It is a bit of a pity that we have to expose the internals here, but I
> > don't see an easy way to avoid that, especially since hppa requires
> > 16-byte alignment. At least <machine/spinlock.h> doesn't do any
> > namespace pollution as I believe a single underscore is enough here as
> > everything is in file scope?
> >
> > This will require a libpthread major bump, and those are really
> > painful! So I'm not sure we should do this just for pshared
> > semaphores which hardly anybody uses.
> >
> > I wonder if we do this, should we include some additional padding in
> > the struct for future expansion?
>
> We can also expose only a padded struct sem { int _pad[4]; } or so.
> That's a bit more cumbersome, and we need to be careful. But certainly
> possible.
Tricky since _atomic_lock is actually an array on hppa and need
16-byte alignment. And the lock is actually used on hppa.
On the other hand, opaqueness would allow us to ditch the lock member
on architectures that use the futex.
> If this is useful, I think we should also consider removing the
> indirection from pthread and mutex, etc. This is more work, but I
> don't mind doing it all at once. Semaphore is just first priority.
Yes. I think the situation where pshared semaphores work pshared
mutexes don't work would be a little bit awkward.
> (I think the mail issues are better now, thanks everyone.)
Looks like it.
