[zeromq-dev] zloop with fd support and timer cancelling
kim at dfusion.com.au
Wed May 25 14:58:32 CEST 2011
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev