I've spent a couple years now on MPI ABI stuff, and I think it would be really good for OpenSHMEM to define an ABI for shmem_team_t and related opaque types.
We are wrapping OpenSHMEM with Python in https://github.com/mpi4py/shmem4py and it is quite difficult because CFFI cares whether shmem_team_t is a pointer or an integer. Cray is using an integer (unsigned long) while everyone else seems to be using a pointer.
I asked Cray to change their ABI but am not optimistic about the outcome (they haven't responded yet but it has only been -2 business hours since I asked). However, it would make a lot more sense for everybody to just decide on an ABI so there is no doubt for users.
To summarize hundreds of hours of analysis and debate from the MPI effort, incomplete struct pointers (ala Open MPI) is the best ABI for such opaque types.
I know that most SHMEM users don't really care about ABI related things like being able to LD_PRELOAD different implementations with an existing binary, but both this and the use of OpenSHMEM from languages that are not C greatly benefit from this.
I've spent a couple years now on MPI ABI stuff, and I think it would be really good for OpenSHMEM to define an ABI for
shmem_team_tand related opaque types.We are wrapping OpenSHMEM with Python in https://github.com/mpi4py/shmem4py and it is quite difficult because CFFI cares whether
shmem_team_tis a pointer or an integer. Cray is using an integer (unsigned long) while everyone else seems to be using a pointer.I asked Cray to change their ABI but am not optimistic about the outcome (they haven't responded yet but it has only been -2 business hours since I asked). However, it would make a lot more sense for everybody to just decide on an ABI so there is no doubt for users.
To summarize hundreds of hours of analysis and debate from the MPI effort, incomplete struct pointers (ala Open MPI) is the best ABI for such opaque types.
I know that most SHMEM users don't really care about ABI related things like being able to
LD_PRELOADdifferent implementations with an existing binary, but both this and the use of OpenSHMEM from languages that are not C greatly benefit from this.