On 08/11/10 07:07 PM, Brock Pytlik wrote:
On 08/11/10 06:29 PM, Shawn Walker wrote:
On 08/ 9/10 04:20 PM, [email protected] wrote:
[snip]
- line 1013: Would it be possible to make the Queue larger, and
simply place a limit on how many of each operation may occur in
parallel? That is to say, if you're already running a
rebuild-index, and you get a request for a second rebuild-index,
could we just accept the second and ignore it instead of returning
an error?
It's intentional that only one process be queued up at a time. Since
almost every operation that would be placed in the queue is long
running and because some operations might conflict with each other, I
wanted it to be setup so that you could only queue up a single
operation at a time so that you didn't end up with (say) 20 index
operations all waiting to be processed ;)
Since I raised this in my review as well, let me chime in.
I think a compatible, and perhaps more user friendly approach would be
to allow a user to queue up many actions, and coalesce identical
consecutive ones in the queue. Let's say I publish 1000 packages. I
start the index updating. Then I realize that a package I expected to be
in the repo isn't there. It'd be nice to be able to publish the missing
package and tell the depot to do an indexing again the next chance it
gets. Alternatively, providing an abort lever for whatever task is being
done in the background would (probably) be sufficient (while stop is
defined for the class, I saw no use of it in the code).
What I don't think is ok is to tell the user they have to wait for
indexing N packages before he can indicate that he'd like the package he
just published included in the indexing.
I think that the right answer for now is to stick with a simpler, easy
to understand mechanism and should we find that we need something more
advanced in this area, we can revisit it.
While the sort of mechanism you're talking sounds potentially useful, it
would also significantly complicate the implementation and be more
difficult to explain to the user.
Cheers,
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
