On Wed, Jan 13, 2010 at 08:34:45PM -0600, Shawn Walker wrote: > It's very simple. Just as callers don't want to wait for an > indeterminate amount of time for file retrieval by transport, I > believe they don't want to wait an indeterminate amount of time for > an image lock.
I don't think these cases are equivalent. In one scenario you're talking to a machine over a network, in the other you're in the same address space or at least the same OS. > I personally, as a developer, would not want to wait "forever" for a > lock. For one thing, if my app isn't multi-threaded, I'd have no > way to be responsive to the user or provide progress information to > the user. > > I have been unable to find any information that indicates how long > the python will wait for a thread lock before timing out (it appears > to be "forever" in my experience) or a file lock. This seems like a false dilemma to me. I'm not suggesting that anybody wait forever. Instead, I'm saying that the API's callers either know that they're willing to wait for the operation to complete, or that they know they don't want to block. If we're blocking forever, that's a deadlock and something we need to fix. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
