Open nspark opened 4 years ago
Elsewhere, we define most (all?) team-based operations to be no-ops for SHMEM_TEAM_INVALID.
I'm not sure, where @nspark came up with this conclusion. If this is correct, then the usage of shmem_team_ctx_create
is incorrect in this example https://github.com/gmegan/specification/blob/teams/example_code/shmem_team_context.c
. Implementations should handle the INVALID scenario, and there shouldn't be any check necessary in the example.
At the 5/21 reading, it was noted that the then-current draft had inconsistent language toward handling invalid teams; e.g., "If team
is invalid, the behavior is undefined. If team
is SHMEM_TEAM_INVALID
, the return value is 1."
Absent any feedback from anyone else, I tried to reconcile the two where the goal was consistency; tipping the scales for special handling of SHMEM_TEAM_INVALID
was to simplify some behavior for users (akin to free(NULL)
being well defined). See 0034139, 65faf2b, be43a4b for examples. There are likely some routines that I missed these changes; shmem_team_translate_pe
may be one.
This created the situation in which most team-based operations were no-ops for SHMEM_TEAM_INVALID
. If that's not what we want to settle on, I'm fine rolling back those changes.
Currently, the collectives intro says:
Should we leave this as-is, or should collectives on
SHMEM_TEAM_INVALID
be treated as no-ops?Some points in favor of treating them as no-ops:
SHMEM_TEAM_INVALID
. This would make collectives consistent with those other operations.