Code review comment for lp:~jtv/juju-core/generic-locking-test
Revision history for this message
| John A Meinel (jameinel) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
LGTM though maybe it could be tweaked a bit.
https:/
File environs/
https:/
environs/
You could probably buffer proceed so that function gets a bit more time
to hang itself. We don't need 'function' to *wait* until the main loop
gets to this point, so buffering the channel makes sense to me.
https:/
environs/
rope to hang itself.
On 2013/06/20 02:47:22, thumper wrote:
> You could have a few sleep(0) type calls, as this should do the same
thing.
runtime.GoSched exists in 1.1, and we want to support using 1.1 (just
not require it).
Is there a reason you can't just add those calls?
https:/
environs/
obey lock"))
Rather than panic to indicate failures, you could have this function
take a c *C and then call c.Assert instead.
Or use Tim's idea and make it a Checker.
https:/
environs/
release lock"))
I would think that supporting the Locker interface might be more useful
than this final assert. I guess the tradeoff is that you would have to
do something like try to acquire the lock, which potentially leaves you
with a hanging test. (Right now if function doesn't release the lock,
you get a panic, the alternative would give you a hanging test).
I just know a fair amount of code uses a RWMutex rather than only a
plain Mutex, and it seems a shame to need to have 2 code paths for
something so similar.
Also, you could use runtime type assertions to still confirm the Mutex
behavior. Just use:
if mutex, ok := lock.(*sync.Mutex); ok {
blankMutex := sync.Mutex{}
...
}
Or even a:
switch lock.(type) {
case *sync.Mutex:
...
case *sync.RWMutex:
...
}
https:/