3 ms·

Does FIDL have no more overhead than a non-inter-process statically dispatched C function call to a non-inlined destination? Does it enable the multi-language e

Does FIDL have no more overhead than a non-inter-process statically dispatched C function call to a non-inlined destination? Does it enable the multi-language equivalent of allocating freely mutable data structures (like structs and std::vector and Rust enums) in one file, and accessing its fields or calling inlined methods in another file in the same language? One thing I've observed is Protobuf has caveats when mutated in-place (used as in-memory mutable application state) and Cap'n Proto is effectively impossible to resize objects, whereas std::vector<complex struct> is difficult to access across languages without treating it as a pointer to opaque type.

surajrmal 5y ago
No, FIDL is optimized for IPC, not in process communication. That said I think it can be used quite well for use cases where you can stomach the overhead of an in process channel such as go channels or rust mpsc. Personally, I think channel based communication is one of the more viable cross language communication strategies.
kentonv 5y ago
> One thing I've observed is Protobuf has caveats when mutated in-place (used as in-memory mutable application state) and Cap'n Proto is effectively impossible to resize objects To clarify slightly: Encoded Protobufs cannot be mutated in-place at all. You have to parse into language-specific in-memory objects, mutate those, and then serialize again. Cap'n Proto does support in-place mutation, with the caveat that if any object changes size, it'll be moved to the end of the message, leaving behind a "hole". You can "garbage collect" the holes by copying the whole tree into a new message, which should be much less expensive overall than parsing and serializing the whole message as Protobuf would require.
- nyanpasu64 5y ago
  Sorry for that. In any case, is it practical to design cross-language FFI ABIs with a "wide" API like C++ or Rust code, without constraining interaction through a narrow inexpressive waist like text over HTTP, bytes or serialization over system calls or IPC, or arguably COM opaque objects?
  - kentonv 5y ago
    Mostly I'd say "no". At least, not much better than Cap'n Proto supports now. If you could convince multiple languages to share the same notion of a heap (including how to malloc() and free() memory), you might be able to get closer, allowing for truly mutable objects without the caveats Cap'n Proto has. However, memory allocation is a major place where languages tend to differ wildly.
    - foota 5y ago
      That's basically what wasm attempts.
malkia 5y ago
for protobufs (probably not the best example, but still) there is a way to improve the performance if you sacrifice some of the functionality. For example https://perfetto.dev/docs/design-docs/protozero https://perfetto.dev/docs/design-docs/protozero (perfetto is a profiling system, and uses (AFAIK) protobuf to communicate data between the system/app and itself).

surajrmal 5y ago

No, FIDL is optimized for IPC, not in process communication. That said I think it can be used quite well for use cases where you can stomach the overhead of an in process channel such as go channels or rust mpsc. Personally, I think channel based communication is one of the more viable cross language communication strategies.

kentonv 5y ago

> One thing I've observed is Protobuf has caveats when mutated in-place (used as in-memory mutable application state) and Cap'n Proto is effectively impossible to resize objects To clarify slightly: Encoded Protobufs cannot be mutated in-place at all. You have to parse into language-specific in-memory objects, mutate those, and then serialize again. Cap'n Proto does support in-place mutation, with the caveat that if any object changes size, it'll be moved to the end of the message, leaving behind a "hole". You can "garbage collect" the holes by copying the whole tree into a new message, which should be much less expensive overall than parsing and serializing the whole message as Protobuf would require.

nyanpasu64 5y ago
Sorry for that. In any case, is it practical to design cross-language FFI ABIs with a "wide" API like C++ or Rust code, without constraining interaction through a narrow inexpressive waist like text over HTTP, bytes or serialization over system calls or IPC, or arguably COM opaque objects?
- kentonv 5y ago
  Mostly I'd say "no". At least, not much better than Cap'n Proto supports now. If you could convince multiple languages to share the same notion of a heap (including how to malloc() and free() memory), you might be able to get closer, allowing for truly mutable objects without the caveats Cap'n Proto has. However, memory allocation is a major place where languages tend to differ wildly.
  - foota 5y ago
    That's basically what wasm attempts.

malkia 5y ago

for protobufs (probably not the best example, but still) there is a way to improve the performance if you sacrifice some of the functionality. For example https://perfetto.dev/docs/design-docs/protozero https://perfetto.dev/docs/design-docs/protozero (perfetto is a profiling system, and uses (AFAIK) protobuf to communicate data between the system/app and itself).