Re: Add a mountlist iterator (round 2)

[Chuck Silvers <chuq%chuq.com@localhost>]

have you considered a callback-based interface where the loop
is inside the iteration API rather than in the caller?
the vfs_busy/unbusy could also be hidden in the iteration API
so that the callback would not need need to worry about it at all.

I looked at how the iteration stuff is used in your patches
(the first one, I haven't looked in the latest one in detail)
and it looks like most of users would be fine with not being able
to do anything after vfs_unbusy().  the one place that really does
want to do more after vfs_unbusy() is vfs_unmountall1(),
but that could be rewritten to loop unmounting the last mount
in the list until they're all gone.

I think this would further simplify most (if not all) cases of
mountlist iteration.

-Chuck


On Tue, Apr 04, 2017 at 10:02:27AM +0200, J. Hannken-Illjes wrote:
> Time to start a second round.  This time the iterator only, vfs_busy()
> and friends deferred to a new thread once the iterator is done.
> 
> Changes from the previous proposal:
> 
> - Removed the "flags" argument from mountlist_iterator_next(), will
>   add mountlist_iterator_trynext() and vfs_trybusy() when needed.
> 
> - Added "void mountlist_iterator_done(mount_iterator_t *)" to
>   completely hide vfs_busy()/vfs_unbusy() from the API and make it
>   possible to assert that every call to mountlist_iterator_next()
>   gets accompanied by a call to mountlist_iterator_done().
> 
> - Use the existing lock "mountlist_lock".
> 
> A typical usage is:
> 
> 	mount_iterator_t *iter;
> 
> 	mountlist_iterator_init(&iter);
> 	while ((mp = mountlist_iterator_next(iter)) != NULL) {
> 		... 
> 		mountlist_iterator_done(iter);
> 	}
> 	mountlist_iterator_destroy(iter);  
> 
> Diffs are here: https://www.netbsd.org/~hannken/ml_iterator2/
> 
> Comments or objections anyone?
> 
> --
> J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)