chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Updating the zmq egg


From: Dan Leslie
Subject: Re: [Chicken-users] Updating the zmq egg
Date: Thu, 05 Mar 2015 17:18:09 -0800

You might want to consider the nanomsg egg, which doesn't appear to have
a wiki page yet.

https://github.com/Adellica/chicken-nanomsg

-Dan

Matt Gushee <address@hidden> writes:

> Hello, folks--
>
> I am developing a distributed application for which I would like to use
> ZeroMQ. I've discovered, however, that the zmq egg is unmaintained and very
> out of date (the egg is compatible with libzmq 2.x, while the current
> stable version of the C library is 4.05).
>
> The good news is that I was able to bring all the foreign type definitions
> and API calls up to date, and the code compiles. I don't know yet if its
> behavior is correct (in fact I know of one thing that is probably incorrect
> - see below). Anyway, I have several questions related to this.
>
> First of all, shall I take over maintainership of the egg? I'm not really
> the best person to do this kind of thing - I'm not really a C programmer,
> and have no real-world experience with ZeroMQ yet. But if there is no
> better-qualified person available, I'm willing to take on this task. If my
> plans work out, I expect to be using the egg for several years at least.
>
> Second, the egg documentation mentions that the egg "has some known
> problems." Can Moritz or someone tell me what those problems are?
>
> Next, there are a couple of details of the code I'm wondering about. One of
> the significant API changes is in the 'zmq_send' and 'zmq_recv' functions.
> Both these functions now take a 'len' argument, representing the size of
> the message buffer. Their signatures are as follows:
>
> *    int zmq_recv (void *socket, void *buf, size_t len, int flags);*
>
>
> *    int zmq_send (void *socket, void *buf, size_t len, int flags);*
> Does a size_t argument require any special handling on the Chicken side? Or
> can I just treat it as a regular integer?
>
> Another issue with message length is whether there should be a default
> value. There is a Scheme function that generates a buffer for both sending
> and receiving functions. Its signature looks like this:
>
> *    (initialize-message message #!optional data)*
>
> The DATA argument is provided when the buffer is used for sending, and not
> when it is used for receiving. When there is data, the buffer size - and
> the 'len' argument to 'zmq_send' is derived from the length of the data.
> The problem arises when receiving a message - when there is no data. For
> the time being I set the default value to 0 - but that clearly is not going
> to be a useful value. I suppose the best size for the message buffer would
> vary greatly according to what type of application you are building, but
> there has to be some sort of number. Can anyone suggest a reasonable
> default (the ZeroMQ API doc includes a usage example with a value of 256,
> but I have no idea how arbitrary that is). Or maybe there just shouldn't be
> a default, and INITIALIZE-MESSAGE should require a buffer length argument
> in cases where no data is provided. Any opinions about this?
>
> Finally, if I am going to maintain this egg I would like it to have a test
> suite. However, I'm somewhat at a loss as to how to test a networking
> library. Simple unit testing is not going to do much good. Any ideas about
> how to approach this?
>
>
> Thanks for any feedback,
> Matt Gushee
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/chicken-users

-- 
-Dan Leslie



reply via email to

[Prev in Thread] Current Thread [Next in Thread]