Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

opaque types need an ABI #499

Open
jeffhammond opened this issue Jul 31, 2023 · 0 comments
Open

opaque types need an ABI #499

jeffhammond opened this issue Jul 31, 2023 · 0 comments

Comments

@jeffhammond
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant