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

[Barak Amar]

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 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.
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.
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.

-- Barak

On Fri, Feb 20, 2009 at 11:06 AM, Martin Sustrik <sustrik at fastmq.com> wrote:

>
>  Still don't know the code very well, but in case the C API will return the
>> qid and we could decode the message type, we may consider warp the byte[] in
>> a Message class something like:
>>
>>    public class Message
>>    {
>>        public static readonly Message Empty = new Message();
>>        public static readonly Message Gap = new Message();
>>        public static readonly Message Delimiter = new Message();
>>
>>        public byte[] Data { get; set; }
>>    }
>>
> ...
>
>> I'm I lost or this is what you were talking about?
>>
>
> No. You are on a right track. It's only to decided whether above "message
> object" is the right way to go or whether getting message data as a return
> value + queuid & message type by reference would be a better solution.
>
> Some random thoughts:
>
> The P/Invoke code would work for both .NET and Mono, right? If so, we can
> actually replace existing .NET implementation by this generic solution.
>
> If byte array is returned from a function, does it mean that the data are
> copied? If so, it may worsen the performance, especially for large messages.
>
> If we are going to ship P/Invoke implementation depending on C API, I would
> invest some time in improving the C implementation:
>
> 1. Add mask and message types to C API.
> 2. Improve the performance of C API by avoiding copying message data
> (memcpy) in czmq_receive.
>
> Makes sense?
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090221/64c9a93c/attachment.htm>