[PVFS2-developers] patch: misc. memory cleanups

Phil Carns pcarns at wastedcycles.org
Tue Jun 7 04:13:37 EDT 2005

Yeah, that's pretty much it.  With the way that loop is ordered now, you 
could just as easily call qlist_del before freeing, but it doesn't 
matter since the part of the code you are talking about 
(job_desc_q_cleanup()) is destroying the queue elements as it goes.  It 
might make it look a little less odd if you put the delete in though.

The main thing in that code block (aside from tossing those mutex locks) 
was to avoid using the do while, in which the while condition relied on 
the value of a free'd pointer.  Happens to work, but isn't the nicest 
way to do things :)

If you have time, don't forget to look at this pvfs2-cp fix too, though 
I didn't give a patch for it:
The abridged version is that strip_size should be of type PVFS_size 
rather than int to make the -s option on pvfs2-cp work again.


Robert Latham wrote:
> On Wed, Feb 16, 2005 at 08:48:18PM +0100, Phil Carns wrote:
>>prevents job desc queue from counting on value of previously free'd 
>>pointer when iterating queue at one point
> Hi phil
> Yeah, it's been -- wow -- nearly 4 months since you sent these
> patches.  I'm looking at the two I wasn't sure about now.  
> I can see where after your changes job-desc-free iterates over the
> linked list:
> 	qlist_for_each_safe(iterator, scratch, jdqp)
> then picks nodes from the list:
> 	tmp_job_desc = qlist_entry(iterator, 
> 	 	struct job_desc, job_desc_q_link);
> and frees the node
> 	free(tmp_job_desc);
> I'm pretty shakey on the qlist methods.  We presently call
> job_desc_q_remove(), which in turn calls qlist_del, which in turn
> fixes up the linked list pointers.  
> Is it the case that since we are going to end up with an empty list
> that we don't need to care about calling qlist_del?
> Thanks
> ==rob

More information about the PVFS2-developers mailing list