Mark Kettenis <mark.kette...@xs4all.nl> wrote:
> > 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.
Yes that's a good point:
If you pad for the future, use the maximum-sized types, thereby trying to
anticipate the future.
It might not be enough for the bizzare hppa case, but it might help other
architectures...
