Support "recursive" calls in MapMaker computingMap (ComputingCurrentHashMap)

[gissuebot]

Original issue created by harman.peter on 2010-06-14 at 08:25 PM

---

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?

[gissuebot]

Original comment posted by kevinb@google.com on 2010-07-30 at 03:56 AM

---

(No comment entered for this change.)

---

Labels: -Priority-Medium

[gissuebot]

Original comment posted by yrfselrahc on 2011-01-26 at 07:21 PM

---

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?

---

Status: WontFix

[gissuebot]

Original comment posted by yrfselrahc on 2011-01-26 at 07:28 PM

---

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

---

Status: Accepted

[gissuebot]

Original comment posted by ian.b.robertson on 2011-01-27 at 12:40 AM

---

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.

[gissuebot]

Original comment posted by jim.andreou on 2011-01-27 at 02:37 AM

---

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).

[gissuebot]

Original comment posted by kevinb@google.com on 2011-01-27 at 02:08 PM

---

(No comment entered for this change.)

---

Labels: -Type-Defect, Type-Enhancement

[gissuebot]

Original comment posted by fry@google.com on 2011-04-08 at 01:17 AM

---

(No comment entered for this change.)

---

Status: Fixed
Labels: Milestone-Release09