Avoiding allocation in broadcast server

[Jakob Ovrum]

On Friday, 7 February 2014 at 23:57:03 UTC, Stanislav Blinov 
wrote:
> To me it seems that you have to have at least one allocation 
> per string received.
>
> To submit your string to another thread verbatim, you have to 
> be able to guarantee that the buffer is immutable, which you 
> cannot do because you can receive a new string at any given 
> time (which would overwrite the existing buffer).
>
> So allocating on receive seems like the most logical option.

Yes, this seems true to me too.

However, if this one allocation really is a problem, you might 
want to implement a simple free-list kind of allocator to 
allocate from. Say, pre-allocate N string buffers with M length 
and treat them as a free-list. If the free-list is full (all N 
buffers are being processed), wait until there is a free space 
before reading another datagram from the socket.

This makes program performance deterministic depending on the 
worst-case complexity achieved when allocating from the 
free-list. GC cycles are never run if the program doesn't 
allocates GC memory.