On Sat, May 17, 2014 at 3:12 PM, Kevin Ballard <[email protected]> wrote:
>
> A common workaround here is to add a parameter of type Option<Self>, so you 
> can pass None in order to provide the correct type info:

Ahh, clever workaround, thanks. I'm looking forward to see how the
underlying issue is resolved in the future.

> I do have to wonder, though, how you intend to map from the type pointer back 
> to the original type. Or do you not need to go in that direction?

This is a great question, and i'm not entirely sure yet. The C library
(MPI) has largely two flavors that need to be handled. The first case
are calls that need to be paired together and have their types match:
For example, the C library has:

  MPI_Send(data, len, type)
  MPI_Recv(data, len, type)

where for two processes with matching send/recv should use the same
type. It seems as though one method for making this safe is two use
something akin to channels two link the underlying send/recv methods
for a particular use. At the moment I am exposing the raw-ish
interfaces and not perform any type checking. In fact, it isn't
completely clear how / if using a channel abstraction would affect the
structure of MPI programs. With the low-level interfaces alone I'm not
sure how type checking could be done as correctness is more of a
function of the program execution.

The other type is easier:

  MPI_Sendrecv(datain, dataout, len, type)

which performs a simultaneous send/recv so the type is easy to figure out.

> If you do, I think you'll need to ditch the trait and instead just use an 
> enum:

If I understand correctly, the enum would address the problem of being
handed a DT_INT32 and map it back to the corresponding Rust type? I'm
not sure if this will be an issue or not, because all the interfaces I
can think of force the caller to specify the expected type, which we
can compute from the associated type of a Rust data structure being
operated on. I hope that makes sense.

-Noah
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to