(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.
(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.