On Thu, Aug 12, 2010 at 03:23:47PM -0700, Brock Pytlik wrote: > On 08/12/10 01:59 PM, Shawn Walker wrote: > >On 08/11/10 07:00 PM, Brock Pytlik wrote: > >>On 08/ 9/10 01:03 AM, Shawn Walker wrote: > >>Do the background processes happen in the same process or are they > >>forked out by cherrypy? If it's that same process, then that concerns me > >>as indexing previously happened in a separate process from the depot, > >>which meant the memory it used was returned to the system when the > >>indexing was done, instead of being attached to the depot for as long as > >>it was running. > > > >If the memory usage of the depot server after indexing is a > >concern for the user, they can restart it, or alternatively use > >pkgrepo on the filesystem path of the repository the depot's > >serving. I'm happy to document that in the man pages. > > > >It was intentional that they happen in the same process. > >Ultimately, I didn't feel that the complexity or problems involved > >with forking were worth it to solve a resource issue. > Ok, please include that information at least in a flag day since it > means that people deploying pkg.depotd should potentially change how > they do things. Have you discussed this w/ Eric to make sure that > we'll be making the appropriate changes?
It's probably RE who needs to be contacted. The repositories should be delivered with an index already built. RE may need to change their process, but we only rebuild the index if it has been mis-delivered. > >>There's no way to abort a task running in the background? > > > >No, and that's intentional. I don't want to implement an overly > >complex mechanism here. There was no way to stop a background > >indexing either in the past, so this isn't any worse than what we > >already had in this way. > I don't understand why you don't want to allow the user some method > of stopping a potentially very long running action short of nuking > their entire depot. I'm fine with simple mechanisms, but not when > the desire for code simplicity makes users lives more difficult. If > they can't queue up more than one background task, I think some kind > of abort really is necessary (and I'd argue even with the ability to > queue up background processes, abort would be useful). What's the use case for this? Wouldn't it lead to more errors if we allow the index to be partially built? In Shawn's proposal, the only way you can end up with a partial index is if the software crashes or is kill(2)'d. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
