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

[Barak Amar]

Hi Dirk and Martin,
Thanks Dirk for the Dispose pattern, forgot about it - spending too much
time in C++.

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; }
    }


This way we can implement the C# receive:

        public int Receive(out Message msg)
        {
            if (zmq_ == IntPtr.Zero)
                throw new NullReferenceException("queue must be
initialized");
            IntPtr ptr;
            UInt32 dataSize;
            FreeMsgData freeFunc;
            int qid = 1; czmq_receive(zmq_, out ptr, out dataSize, out
freeFunc);

            // check the type and return Message.Gap or Message.Delimiter
            if (ptr == IntPtr.Zero)
            {
                msg = Message.Empty;
                return qid;
            }

            msg = new Message();
            msg.Data = new byte[dataSize];
            Marshal.Copy(ptr, msg.Data, 0, Convert.ToInt32(dataSize));
            if (freeFunc != null)
                freeFunc(ptr);

            return qid;
        }

I'm I lost or this is what you were talking about?

-- Barak

On Thu, Feb 19, 2009 at 5:18 PM, Martin Sustrik <sustrik at fastmq.com> wrote:

> Dirk, Barak,
>
>  How to tell apart message_gap from non-blocking receive is TBD, I image
>> that a return of zero means no data in non-blocking mode, and returning a
>> null pointer for the data indicates a gap in a given queue.
>>
>
> Hm, would it be possible to return a triple (int queue-id, int
> message-type, Array<Byte> message-body)? That way the mechanism would be
> future proof allowing for new types of notifications.
>
> (No idea how .NET handles things like "triple" myself.)
>
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090220/2bef95a0/attachment.htm>