search

maidh91 / guava-libraries

Automatically exported from code.google.com/p/guava-libraries
Apache License 2.0
0 stars 0 forks source link

Support "recursive" calls in MapMaker computingMap (ComputingCurrentHashMap) #369

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Create a computing map using MapMaker.makeComputingMap
2. In the computing function, make a call to .get(key) on the map with the same 
key
3. Pretend this isn't a stupid example despite looking it

What is the expected output?
- An exception

What do you see instead?
- The current thread freezes

What version of the product are you using? On what operating system?
v5

Please provide any additional information below.
- This might seem a strange example, but it is representative of an issue we 
have where we use a map as a cache, but the computing function often requires 
another object from the cache, and it is possible for this to be recursive. It 
can't be guarded against within the computing function, because it is not 
called a second time for the same key, the thread blocks instead.
- I'm wondering whether it is possible to (optionally) check if a key is 
already being used in a computing function in the same thread and throw an 
exception?

Original issue reported on code.google.com by harman.p...@googlemail.com on 14 Jun 2010 at 8:25

GoogleCodeExporter commented 9 years ago

Original comment by kevinb@google.com on 30 Jul 2010 at 3:56

GoogleCodeExporter commented 9 years ago 
I can't conceive of a use case where this would be the proper architecture. 
Assuming that MapMaker allowed recursive computation, how do you prevent 
infinite recursion?

Original comment by yrfselrahc@gmail.com on 26 Jan 2011 at 7:21

GoogleCodeExporter commented 9 years ago 
On second thought, even though the value of recursive computation is not 
obvious to me, it couldn't hurt to fail fast.

Original comment by yrfselrahc@gmail.com on 26 Jan 2011 at 7:28

GoogleCodeExporter commented 9 years ago 
One (actual live) use case is using MapMaker to create a map from class to 
instance implementing the class (think service lookup).  Instances may require 
other instances during initialization, which would require going back to the 
MapMaker.  If, due to developer error, there is a circular dependency, it would 
be preferable to have an exception thrown with sufficient diagnostic 
information allow the developer to fix the root cause.

Original comment by ian.b.ro...@gmail.com on 27 Jan 2011 at 12:40

GoogleCodeExporter commented 9 years ago 
1. Adding this to MapMaker would mean additional overhead for the vast majority 
of uses that don't need this. 
2. I haven't thought through it, but can't the user implement cycle detection 
himself? Using a ThreadLocal with a stack or a set or so. (This might even 
deadlock though, but it would still be an improvement).

Original comment by jim.andreou on 27 Jan 2011 at 2:37

GoogleCodeExporter commented 9 years ago

Original comment by kevinb@google.com on 27 Jan 2011 at 2:08

GoogleCodeExporter commented 9 years ago

Original comment by fry@google.com on 8 Apr 2011 at 1:17

GoogleCodeExporter commented 9 years ago 
This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:15

GoogleCodeExporter commented 9 years ago

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:10