objid_t: adapt callbacks to use objid_t

heyram commented 11 years ago

Original issue: https://charm.cs.illinois.edu/redmine/issues/179

Evaluate the implications of objid_t (basic implementations in #170) on callbacks and improve callback design / implementations where possible. There are some protocol issues to consider.

For eg: if a callback is supposed to store an objid_t, but the application is executing under a distributed lookup configuration, the objid_t corresponding to a given index may not be available at construction time of the callback. In fact, the corresponding element might not even have been created, which means there is no objid to stuff into the callback.

Assuming objid_t percolates completely into the runtime, we may choose to make array indices variable sized. This would imply that the callbacks now need to hold / transmit var-sized array indices (and cannot be PUPbytes).

There seem to be a few considerations here, but any design improvements in callbacks may be worth making.

PhilMiller commented 5 years ago

Original date: 2013-10-07 19:05:53

This won't be ready for 6.6, so push it back.

epmikida commented 5 years ago

Original date: 2017-04-10 17:29:07

I'm currently working on getting the 64bit ID used for things other than chare arrays (singletons, groups, nodegroups). Once that is complete, updating proxies and callbacks to use 64bit IDs will be straightforward, however the first step of 64bit IDs everywhere will require a bit of legwork that won't be ready for 6.8.

charmplusplus / charm

objid_t: adapt callbacks to use objid_t #179