Comment #15 on issue 183 by crazybob...@gmail.com: Scopes.SINGLETON uses a global lock
http://code.google.com/p/google-guice/issues/detail?id=183
Empirical observation is no substitute for correctness. If we lock at binding granularity, users will see duplicate singletons and deadlocks. There's no room for debate here.
Today, you'll only see a deadlock if you spawn a thread during injection, access the injector from that thread, and then wait for that thread to complete. The solution is simple: don't do that. Comparable or better solutions almost always exist.
Can we make the lock finer grained? We could lock on the associated Injector instance instead. A Scope implementation doesn't currently have access to the Injector. You could access it through a thread local, but this would hurt performance for everyone, or you might be able to pass in a special Provider subclass as the creator which would have a ref to the injector, but it could be tricky or impossible to track down all of the edge cases.
Can we do something more clever? You need a) something like STM, which doesn't exist for arbitrary Java code, or b) a new design that's 100% statically analyzable so you can figure out which locks you'll need ahead of time (this would be a very different API than Guice provides).
-- You received this message because you are subscribed to the Google Groups "google-guice-dev" group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
