On Tue, Oct 13, 2009 at 10:06:36AM -0700, Danek Duvall wrote: > [email protected] wrote: > > > http://cr.opensolaris.org/~johansen/webrev-11854/ > > General high-level comment: > > This might be better structured with a synchronization decorator, such > as the one demonstrated at > > http://code.activestate.com/recipes/465057/
http://wiki.python.org/moin/PythonDecoratorLibrary#Synchronization Thanks. I actually looked at a similar recipe, above, and ended up passing on the idea. > That would allow you to not have to separate all these methods out into > two quite as conspicuously. Now, that alone may not work, since the > Lock objects aren't recursive, so you'd probably have to switch to an > RLock object, which I think is safe, because you're only trying to > prevent different threads from using the transport object > simultaneously. Yes, although I'd prefer to avoid recursively grabbing locks. The other concern that I had was that the synchronization decorators need an external lock, while I'd prefer to have a lock per Transport instance. I may be missing some key aspect of how decorators work, but I was under the impression that the locking had to work like the recipe, in order for the decorator to be useful. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
