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

[Martin Sustrik]

One more idea still: If there's a CLI message object as Barak proposed, 
it can hold the native message_t object and thus we don't have to care 
about copying/pinning on CLI level at all. Just pass message_size as an 
argument to the constructor and the object will allocate unmanaged 
memory itself:

class Message
{
public:
     Message (int size) : msg (size) {}
private:
     message_t msg;
};

The only question is how to make it convenient for the user to fill in 
the buffer content. C++ API simply allows you to get pointer to the 
buffer, which is efficient but probably not feasible in CLI. Not sure of 
alternatives. Following kind of approach appears rather annoying to use:

SetByte (int pos, byte value)
{
     *(msg.data () + pos) = value;
}

Martin

Dirk O. Siebnich wrote:
> OK, I didn't expect anything else. And of course, fixing objects in the
> CLR heap will not do good for the GC system. I am afraid I will not be
> spending large amounts of time on designing and tinkering.
> 
> -Dirk
> 
> On Sun, 2009-02-22 at 15:00 +0200, Barak Amar wrote:
>> Hi Dirk,
>>
>>
>> About 'fixed' scope in the 'Send' implementation - if 'czmq_send' is
>> blocked until the message is send the code will work, but if the
>> message is put in a queue and the control is back the C#'s 'Send'
>> method, the 'fixed' scope will end and the pointer to the data will no
>> longer be available when the sending thread will access it.
>>
>>
>> -- Barak 
>>
>> On Sun, Feb 22, 2009 at 11:42 AM, Dirk O. Siebnich <dok at dok-net.net>
>> wrote:
>>         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
>>         
>>
>>