Brian Duggan writes:
> On Wednesday, March 21, Justin Mason wrote:
> > It sounds pretty good -- just one thing -- how is a caller supposed to get
> > the datapath? Presumably they don't construct it themselves...
>
> >>From the $job object (obtainable by sending a callback
> to visit_all_jobs()). Though actually, it looks like using
> $job->{pathqueue} instead of the datapath might be easier,
> so that pickup_queued_job() doesn't have to read the
> queuefile (to find out the datapath).
>
> > that's ok, that suggestion is a one-liner. Having said that -- a test case
> > "t" script would rock though :)
>
> Okay, I've attached one.
Cool. That makes the idea pretty clear, too. I had to move a little
stuff around to make it more efficient, but it works fine; I also copied
the test script for fanout and ordered queue modes, too. Checked in:
: jm 516...; svn commit -m "added support to pickup a queued item by its data path, thanks to Brian Duggan <bduggan at matatu.org>"
Sending MANIFEST
Sending lib/IPC/DirQueue.pm
Adding t/60pickup_path_basic.t
Adding t/60pickup_path_fanout.t
Adding t/60pickup_path_ordered.t
Transmitting file data .....
Committed revision 9297.
> thanks!
> Brian
>
> ps On a separate note, I noticed that read_control_file() is always
> called with two arguments, but the second argument is ignored. Is
> this perhaps an alternative to saying 'local *IN' in read_control_file()?
oops! bug ;) Thanks for spotting this. fixed:
: jm 745...; svn commit -m "read_control_file() was always opening the control file for read twice, redundantly; fixed" lib/IPC/DirQueue.pm
Sending lib/IPC/DirQueue.pm
Transmitting file data .
Committed revision 9296.
--j.
Thread Previous