www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Avoiding allocation in broadcast server

reply "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail gmail.com> writes:
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.
Feb 07 2014
next sibling parent reply "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
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.
Feb 07 2014
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
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.
Feb 08 2014
parent "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail hotmail.com> writes:
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.
Feb 08 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
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.
Feb 08 2014
parent "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail gmail.com> writes:
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.
Feb 09 2014