Any limitation in frequency to service the picoquic_callback_prepare_to_send?

[Mike-RandoNumber]

I encountered the phenomenon of pushing the other callbacks into virtual no dynamic existence, if I directly service this callback with a continuation (void)picoquic_provide_stream_data_buffer(context, 0, 0, 1);
Doing so seems to prevent triggering of other callbacks.
Is there a recommendation about waiting/not/waiting in this callback in order to have ressources left for the other threads?

[huitema]

You should only mark is_still_active-1 in the call to uint8_t* picoquic_provide_stream_data_buffer(void* context, size_t nb_bytes, int is_fin, int is_still_active); if the application is ready to send data on that stream on the next callback picoquic_callback_prepare_to_send.

The particular from that you are using, (void)picoquic_provide_stream_data_buffer(context, 0, 0, 1); should only be used in the specific scenario where the callback proposes to send up to length bytes of data, but that is smaller than the minimum amount of data for the application. You are effectively stating: the application has data ready to send, but it needs a larger buffer than what is proposed. The stack will treat that as stating urgency, and will immediately poll the application when preparing the next packet. If the application always respond with that call, it creates a loop.

[Mike-RandoNumber]

Thanks for this insight - I encounter after a short time the effect, that picoquic_provide_stream_data_buffer returns a NULL pointer - how is this situation reconcilable?

[huitema]

picoquic_provide_stream_data_buffer only returns a NULL pointer if the application is asking for a buffer size larger than the "length" indicated in the callback. So, don't do that.