You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The faabric::Message protobuf object is bloated now and has become a dumping ground for lots of context. Having a single message format is very convenient, and necessary because of the breadth of different types of calls we support.
I think we can refactor as follows:
Move all Faasm-specific flags into custom serialised contexts held in the BatchRequest::contextData field. This is what we do with OpenMP, and can be applied to all SGX- and Python-related fields on the Message.
Move all MPI-related fields into a nested MPI context.
Collect all feature flags into a nested flags object (isAsync, isStatusRequest etc.).
Move all batch-wide properties onto the BatchRequest, e.g. snapshotKey, appId, masterHost, executesLocally, groupId
Create a separate protobuf object for exec-graph data.
The text was updated successfully, but these errors were encountered:
The
faabric::Message
protobuf object is bloated now and has become a dumping ground for lots of context. Having a single message format is very convenient, and necessary because of the breadth of different types of calls we support.I think we can refactor as follows:
BatchRequest::contextData
field. This is what we do with OpenMP, and can be applied to all SGX- and Python-related fields on the Message.flags
object (isAsync
,isStatusRequest
etc.).BatchRequest
, e.g.snapshotKey
,appId
,masterHost
,executesLocally
,groupId
The text was updated successfully, but these errors were encountered: