SHM lazy init is now configured in config.json

[yellowhatter]

Adds SHM lazy init behavior control through config

"lazy" was the only behavior of SHM before this PR: initialize SHM internal data and threads on-demand (which means "at first SHM buffer interaction"). This PR adds "init" mode that initializes all SHM stuff at first Session open.

From the config doc:

/// - "lazy": SHM subsystem internals will be initialized lazily upon the first SHM buffer
/// allocation or reception. This setting provides better startup time and optimizes resource usage,
/// but produces extra latency at the first SHM buffer interaction.
/// - "init": SHM subsystem internals will be initialized upon Session opening. This setting sacrifices
/// startup time, but guarantees no latency impact when first SHM buffer is processed.

[Mallets]

In the queue, the lazy initialisation is exposed with this configuration structure:

zenoh/DEFAULT_CONFIG.json5

Line 478 in e4ea6f0

allocation: {

If possible it would be good to adopt a similar structure.

[yellowhatter]

Done!

[Mallets]

It's unclear to me from this PR who the lazy init workflow behaves. Would you mind elaborating it a bit?

[yellowhatter]

It's unclear to me from this PR who the lazy init workflow behaves. Would you mind elaborating it a bit?

"lazy" was the only behavior of SHM before this PR: initialize SHM internal data and threads on-demand (which means "at first SHM buffer interaction"). This PR adds "init" mode that initializes all SHM stuff at first Session open.

From the config doc:

/// - "lazy": SHM subsystem internals will be initialized lazily upon the first SHM buffer
/// allocation or reception. This setting provides better startup time and optimizes resource usage,
/// but produces extra latency at the first SHM buffer interaction.
/// - "init": SHM subsystem internals will be initialized upon Session opening. This setting sacrifices
/// startup time, but guarantees no latency impact when first SHM buffer is processed.

[Mallets]

It's unclear to me from this PR who the lazy init workflow behaves. Would you mind elaborating it a bit?

"lazy" was the only behavior of SHM before this PR: initialize SHM internal data and threads on-demand (which means "at first SHM buffer interaction"). This PR adds "init" mode that initializes all SHM stuff at first Session open.

From the config doc:

/// - "lazy": SHM subsystem internals will be initialized lazily upon the first SHM buffer
/// allocation or reception. This setting provides better startup time and optimizes resource usage,
/// but produces extra latency at the first SHM buffer interaction.
/// - "init": SHM subsystem internals will be initialized upon Session opening. This setting sacrifices
/// startup time, but guarantees no latency impact when first SHM buffer is processed.

Thanks! I thought more things were needed to add the desired behaviour but it's not the case.

LGTM I would then simply address the comment on the configuration.