Suppose I have a multi client broadcast server. One client sends a string, every client receives it. The client read thread reads the input from the client into a static byte array, makes a copy and casts it to a string, and passes it to the host thread, which relays it to all client write threads. This is done with message passing. Is there a way it can be done without allocation? That is, currently I use .idup on the static array.

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.

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.

On Saturday, 8 February 2014 at 11:15:31 UTC, Jakob Ovrum wrote:
> 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.

Meh, it sounds rather ghastly. Perhaps if I periodically call GC.collect instead I can keep it down to a manageable delay.

On Friday, 7 February 2014 at 22:04:31 UTC, Casper Færgemand wrote:
> Suppose I have a multi client broadcast server. One client sends a string, every client receives it. The client read thread reads the input from the client

Client reads from the client? And what does the server?

> Is there a way it can be done without allocation?

There are innumerable ways to do multithreaded programming. They have different tradeoffs in speed, safety and resource consumption.

On Saturday, 8 February 2014 at 17:49:24 UTC, Kagamin wrote:
> Client reads from the client? And what does the server?
Server reads from client and broadcasts to clients.