[zeromq-dev] P/Invoke-based CLR access to zeroMQ

Martin Sustrik sustrik at fastmq.com
Sun Feb 22 09:01:56 CET 2009

Hi Barak,

> The PInvoke implementation can be used for both .NET and Mono, but I 
> still prefer the power I get from C++/CLI not going through C# -> C -> 
> C++ way.

We'll measure this (you can do so as well). If there's no significant 
performance advantage for using C++/CLI over P/Invoke, I would prefer 
having only a single implementation of .NET/Mono API. Less code = less bugs.

> We copy the message bytes into a managed byte array on 'Receive' and 
> free the original copy (if required).  The byte array is passed by 
> reference, so no copy overhead here.

Great. I'm not a CLI developer. I was concerned because returning arrays 
in C++ is a problem - code like this causes whole array to be copied:

vector<int> fx ()
      vector<int> v (1000);
      return v;

We should also think about whether it's possible to avoid the copy from 
message_t to Array<Byte> in the receive function. If message is modeled 
as an object this should be possible in some way.

> Agree that we change the C API for the C# implementation, the same 
> should be done for all languages.  What I mean is that the 0MZ interface 
> for each language Java, C#, Python should supply a common functionality. 
>  So if the C API will give access to the api_thread's mask I should be 
> able to access it also from Python.

Yes, we've already added parameters allowing to control queue limits to 
all languages. Let's move in "same API for all languages" direction in 
the future.

> This will also affect how a 'Message' should be implemented, if any, we 
> can use 'enums' to specify 'gap' and 'delimiter' instead using heap 
> references.

Ok. let's try to get the interface right. To follow "same API for all 
languages" principle, CLI and Python bindings should be based on primary 
C++ interface. Thar would mean that "receive" function should have two 
return value a.) queue-id b.) message-object. Message object itself is 
componsed of two parts: a.) message-type (enum) b.) message body (array).

Let's think about what would be the best way to model this in 


More information about the zeromq-dev mailing list