Skip to content

Conversation

@GiovaGa
Copy link
Collaborator

@GiovaGa GiovaGa commented Dec 9, 2025

Resolves #405

@GiovaGa GiovaGa self-assigned this Dec 9, 2025
Copy link
Member

@anyzelman anyzelman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Intermediary review request to double-check code structure -- and all looks good from that perspective to me=)) Also some minor comments I saw while going through it quickly just now

const void* buf_void = reinterpret_cast< const void* >( buf );

data.ensureMemslotAvailable( 1 );
data.signalMemslotTaken();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this one should come after line 62 (and only if that call returned SUCCESS probably?)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree for after line 62, but I am not sure about the SUCCESS check. There are many kinds of possible errors that could happen, so I think it's safer to take a memslot in any case


// data.ensureMemslotAvailable( 1 ); // this function calls lpf_sync
{
const auto it = data.registered_slots.find( reinterpret_cast< const void* >( dst ) );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it may be more robust to introduce a grb::Scalar type ...but maybe let's worry about that later

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll leave this one open for the day I will actually implement this

@GiovaGa
Copy link
Collaborator Author

GiovaGa commented Dec 17, 2025

Currently I register locally objects needed for put/get and then forget about them.
In theory we could deregister them after a subsequent sync, so @anyzelman do you think it is better to:

  • just keep them, as they may be needed (pro: no need to modify sync function, con: more memory footprint)
  • deregister after every sync (pro: less memory footprint, con: we may have many registration deregistration on the same memory, so it might be suboptimal)
  • We might also implement some kind of caching strategy for this, but that seems definitely overkill

In both cases I will have to implement something to keep track of them.

It might also happen that we a locally registered address is registered globally, and in that case I guess we should deregister locally before registering globally

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

Successfully merging this pull request may close these issues.

Provide put & get message passing primitives for the bsp1d backend

3 participants