[zeromq-dev] P/Invoke-based CLR access to zeroMQ
sustrik at fastmq.com
Sun Feb 22 09:01:56 CET 2009
> 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);
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
> This will also affect how a 'Message' should be implemented, if any, we
> can use 'enums' to specify 'gap' and 'delimiter' instead using heap
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