Concurrency in enterpolation

[luiswirth]

ConstSpace and DynSpace both aren't Send nor Sync, which means that BSplines can't be shared or moved between threads, which makes concurrency hard.
How do I handle this? I'm using enterpolation in a game engine with a concurrent ECS, so I need to be able to do this.

This is in the docs for the Space trait:

/// We do want to generate workspaces every time the method is called as this allows as safe concurrency.
/// This may impact performance as for DynSpace we always allocate memory. However as their is an alternative,
/// this is accepted.
pub trait Space<T>

It should probably say: "However as there is no alternative, this is accepted."

I'm not quite sure what this comment says?
Are you supposed to build the BSpline new everytime?

What is the reason for these spaces being !Send and !Sync?

[NicolasKlenert]

I see you already found the new discussions.

ConstSpace should definitly be Send and Sync and if I'm not mistaken the same should hold true for DynSpace . I think they don't get automatically implemented because they contain a raw pointer in their phantom field (used to "store" the type data). and I did not implement these traits manually.

You are totally correct, it should say "However as there is no alternative, this is accepted". It seems I wrote this comment a little to late in the evening and forgot how to write proper sentences. So basically what the comment is saying is: DynSpace allocates memore every time a BSpline Curve calculates a point. This was by design to allow DynSpace to be Sync.

So in summary there is no reason these spaces are !Send and !Sync. On the contrary, I wanted them to be Send and Sync. I will change this for the next update (as well as the documentation of Space).

If you don't want to wait for the next update, you are always able to implement your own CustomSpace which implements the Space trait and give it to the builder with the workspace() method.

I hope this answers your questions :). If you have any other questions please let me know.

[luiswirth]

Oh okay, that makes a lot of sense, thanks :).
I figured having !Send + !Sync was intentionally andthe reason why you put a PhantomData<*const T> in there.
This clears things up.

Is there a particular reason why you choose *const T? I know you have to use the generic parameter somehow.
I'm not quite sure but I think usually you either use PhantomData<T> (covariant with drop-check), PhantomData<fn() -> T> (covariant), PhantomData<fn(T)> (contravariant), PhantomData<fn(T) -> T> (invariant).

See nomicon.

Using one of these instead of a raw pointer leads to Send + Sync still being implemented. Then we don't need to unsafely implement Send + Sync explicitly.

The choice of which of these you use depends on things like the drop check and subtyping and variance.
I don't really know too much about these topics.

I think we should go with either PhantomData<T> if the space types behave as if they had a owned T inside of them, or PhantomData<fn() -T> if this is not the case.

What do you think?

[luiswirth]

I'm willing to do a PR, once I have green light :).

[NicolasKlenert]

Is there a particular reason why you choose *const T?

I don't know too much of this either, I chose *const T merely because T was not the right option as the spaces don't behave as they would own any type themselves. To be honest, this is the first time I see PhantomData patterns like PhantomData<fn(T) -> T>, so this is a positive surprise for me.

I'm inclined to agree with you on PhantomData<fn() ->T>, as this represents what the spaces are doing. And after reading this explanation of Variance in Rust I'm rather sure that covariant is also the behaviour one wants.

So yeah, thank you for your suggestion, changing PhantomData<*const T> to PhantomData<fn() -> T> is a solution I'm very happy with and which I wouldn't have thought of myself.

A PR in the dev branch would be lovely :)

[luiswirth]

Here's the PR #6 :D

[NicolasKlenert]

The PR was so fast :D. Thanks again. PR is already merged and I will update the version in the coming days.