[zeromq-dev] zloop with fd support and timer cancelling

[Kim Lester]

On 25/05/2011, at 6:34 PM, zeromq-dev-request at lists.zeromq.org wrote:

> Message: 1
> Date: Wed, 25 May 2011 07:10:44 +0200
> From: Pieter Hintjens <ph at imatix.com>
> Subject: Re: [zeromq-dev] zloop with fd support and timer cancelling
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Cc: zeromq-dev at mail.imatix.com
> Message-ID: <BANLkTinxLgZsErZ__TcGm6f7d4jzfxQNRQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi Kim,
> 
> Very neat. I actually wrote half the same code today on the plane,
> needed it to work with FDs for the UDP transport thing I'm making.
> Almost identical changes...
> 
> Not sure about cancelling timers based on delay. That's a bit too
> sneaky, if we have two or three heartbeats going, with the same delay,
> it'll cancel random ones.
> 
> Also, there's no need for separate cancel socket/fd methods, since you
> can pass the poll item and that contains either a socket or fd.
> 
> I've not merged your changes, but pushed mine, let's see how best to
> cancel timers. I'll think about it and experiment. We need to be able
> to cancel specific timers, so that does mean passing some kind of
> reference around.
> 
> -Pieter


Hi Pieter,

Yes I thought cancelling via delay was a bit sneaky, it was quick and "dirty" good for some things but not the general case.
One other way might be to use the timer structure pointer. I was avoiding creating an incrementing id because then it would possibly need mutex protection unless we are going to guarantee the structure is only used by a single thread.

Regarding the separate socket/fd methods, I did consider that and it does make a neater interface. The reason I didn't use that method was simply based on some coding experiences that I had:
As the z_pollitem_t  passed into the create functions is copied by the internal routines it is no-longer needed (I copied the structure because we avoid the who-owns-this-ptr-and-frees-it  problem).
The zmq_pollitem_t variable can thus be discarded after use, indeed I initialise all my sockets with the same pollitem structure, just changing the socket ptr between calls.

Since most programs only need the socket/fd they won't keep the pollitem_t structure around so to cancel a socket we then need to create a new 0 filled z_pollitem_t and set the socket/fd in it. A very minor point.
 
If you continue on the z_pollitem_t struct as the standard interface you _could_ also use it for timers by setting either socket to a timer_ptr or fd to a -ve? timer id.
Although having suggested it I'm very cautious about forcing variables into different uses I think it makes code too easily breakable.
One alternative that might be acceptable - since zsocket_new and zsocket_type etc already exist as partial wrappers around the underlying zmq library, you might be able to add new socket types here (eg a "timer socket" and even a fd "socket") provided you don't pass a zsocket object to the underlying zmq layer it's ok. There are pros and cons but it might work nicely is the wrapping is clean. This method is also extensible.

regards Kim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110525/5ffcca9c/attachment.htm>