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

[Dirk O. Siebnich]

Hi,

I think I am on to something. Please check the Send function. What are
the requirements for data_ buffer to exist beyond the czmq_send
function, i.e. is there any real need for the ffn_ callback?

If the czmq_receive could be modified to request a buffer of an
appropriate size via callback, instead of requiring a ffn_ free
function, we could have zero copies in the P/Invoke interface!

-Dirk

On Sun, 2009-02-22 at 09:01 +0100, Martin Sustrik wrote:
> 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 
> CLI/Python/Java/C...
> 
> Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dnzmq.cs
Type: text/x-csharp
Size: 4876 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090222/3a606c32/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090222/3a606c32/attachment.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3223 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090222/3a606c32/attachment-0001.bin>