[ofiwg] fi_trywait and providers

[Hefty, Sean]

I didn't realize that this email didn't hit the list until today.  The upstream code was updated to option 1.

The main reason to select option 2 or 3 is if we want libfabric 1.3, running with an updated application, to support an older dynamically built provider.

> I have a slight preference for options #1 or #2, but I don't feel strongly
> about it.  Other opinions?
> 
> -Dave
> 
> > On Mar 9, 2016, at 6:24 PM, Hefty, Sean <sean.hefty at intel.com> wrote:
> >
> > The 1.3 libfabric release will contain the fi_trywait call.  For
> providers, there are a couple of options available for handling this.
> >
> > - The libfabric core can check that a provider supports the 1.3 API, and
> reject those that don't.  This is the easy button.
> >
> > - The fi_trywait call can include a check against the provider's fabric
> ops to see if trywait was implemented.  This conditional check would be in
> all fi_trywait paths.
> >
> > - The libfabric core can wrap the provider's fabric ops with its own
> copy of fabric ops.  This requires mapping the provider's fabric fid to a
> core fabric fid for the sake of compatibility.  This is only needed for
> providers asking for API < 1.3.  This is the hard button.
> >
> > - Sean
> > _______________________________________________
> > ofiwg mailing list
> > ofiwg at lists.openfabrics.org
> > http://lists.openfabrics.org/mailman/listinfo/ofiwg