ipc.session (+SHM-enabled): If using MQ transport in a SHM-enabled Session setup but with heap-based struc::Channel, msg size too small => barfs on moderately sized messages. / Deduced MQ msg size should be possinlenti override.

[ygoldfeld]

(CC @wkorbe)

Per title:

If using MQ transport in a SHM-enabled Session setup but with heap-based struc::Channel, msg size too small => barfs on moderately sized messages.

I.e., if you make a Channel_via_heap in this setup and then try to send a message that requires even 1 capnp-segment >= 512 bytes in size -- e.g., by including a List() or Data() and then sizing it to need 1K bytes, trying to send that message hoses the Channel with an error. It's a nice civilized error, but that's small consolation.

(An immediate workaround (of sorts) is to use a non-MQ-based transport when compile-time-configuring the Session_server (etc.). Then the max seg size is always ~64Ki which is plenty.)

Internally the reason is that the channel-setting-up code in ipc_session assumes you'll "just" be using SHM-backed struc::Channels, so only SHM-handles will be traveling, so a small MQ message size is chosen. This behavior is fine by default, but if someone wants to do non-SHM-backed struc::Channels (e.g., messages are small, and the SHM use is direct via Arena::construct<T>), then it is not fine.

Suggested solution: Add a method to Session_server (and the SHM-enabled Session_server 2x based on it), spiritually similar to classic::Session_server::pool_size_limit_mi() x 2 (accessor, mutator). So like mq_msg_size_limit() x 2. Don't forget to put a static_assert() in the body, so that if they try to call it (and thus instantiate this template method) when mq-type template arg = NONE, it'll refuse to build. In that case it is inapplicable. (Note: SFINAE not needed, as it's a class template.) Like pool_size_limit_mi(), it would be formally allowed to be called when async_accept() is not currently outstanding (typically, sometime before the first one, after construction of Session_server). It would affect all init-channels for subsequently-opened sessions; and all open_channel() calls w/r/t that server, including already-existing sessions.

Bug or enhancement: Well, it's acting "as designed" technically. But this part is mis-designed. So... both?

Priority: should get it out in the next release, but it's not an emergency. A definite miss; the use case is slightly exotic but not really.

[ygoldfeld]

I should add... the above description is accurate, and the solution suggested is complete. For clarity though:

The problem need not even have anything to do with struc::Channel at all. Simply, you might make a raw Channel and the MQ msg max size will be 512 - what if you wanted to use the MQ in binary form and not upgrade to struc::Channel over it? Why then must it be 512? What if you want 4? Or 8192? Or 7? It's a general purpose channel.

I guess at the time I coded that part, I was so used to struc::Channel being "the" main use case, I forgot that that's an assumption, and there are plenty of legit IPC uses without it.

So to reiterate, as a default it's fine, but it simply needs to be overridable.

[ygoldfeld]

CC @ntopilsk