I suggest using a template-generated type that can contain any of the messages to be sent over a channel. It is reasonably straightforward to generate all the boilerplate code necessary to make this happen. My prototype (attached) still needs work to remove linux dependencies and tighten it up, but it works ok. Another advantage of this approach (well, I see it as an advantage) is that you declare in a single location all the messages that can be sent over the channel, and of course the messages are type-safe.

The file of interest is concurrency.d.

On 10/02/12 02:14, Sean Kelly wrote:
So a queue per message type?  How would ordering be preserved? Also, how would 
this work for interprocess messaging?  An array-based queue is an option 
however (though it would mean memmoves on receive), as are free-lists for 
nodes, etc.  I guess the easiest thing there would be a lock-free shared slist 
for the node free-list, though I couldn't weigh the chance of cache misses from 
using old memory blocks vs. just expecting the allocator to be fast.

On Feb 9, 2012, at 6:10 AM, Gor Gyolchanyan<gor.f.gyolchan...@gmail.com>  wrote:

Generally, D's message passing is implemented in quite easy-to-use
way, but far from being fast.
I dislike the Variant structure, because it adds a huge overhead. I'd
rather have a templated message passing system with type-safe message
queue, so no Variant is necessary.
In specific cases Messages can be polymorphic objects. This will be
way faster, then Variant.

On Thu, Feb 9, 2012 at 3:12 PM, Alex_Dovhal<alex_dov...@yahoo.com>  wrote:
Sorry, my mistake. It's strange to have different 'n', but you measure speed
as 1000*n/time, so it's doesn't matter if n is 10 times bigger.




--
Bye,
Gor Gyolchanyan.


--
Graham St Jack

Attachment: delve.tar.gz
Description: GNU Zip compressed data

Reply via email to