From:	(Justin Mason)	Date:	Thu Mar 22 13:30:29 2007
Subject:	Re: cancelling queued items

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.