| Issue 10: | thread-safety and static boundary | |
| 1 person starred this issue and may be notified of changes. | Back to list |
I think the doc will have to address the project's mandate on: (a) thread-safety (b) The static boundary. Regarding (b), it is clear that Funcito operates in the static space with respect to execution/memory allocation etc. Will clients ever have the need to call Funcito in a non-static context? Should we state the policy upfront? This has an impact on the internals and esp. any answers to (a). In my view, Funcito should strive to minimize static, beyond the initial static methods for the client API.
Dec 27, 2011
The answer to (a) is that, no, it is not currently thread-safe in the construction of functional objects. Different threads could successively attempt push an invocation before the first thread pops its invocation (i.e., with call to functionFor(), etc.) I wrote a test to prove this. I am working on using ThreadLocal to help solve this. While this is an unlikely occurrence, I can still see realistic scenarios where it might happen. As I think I have stated elsewhere, the actual produced functional objects are inherently as thread-safe as the methods that they wrap. So no issues there.
Status:
Started
Labels: -Type-Design Type-Defect Priority-High Milestone-Release0.1 Usability
Dec 27, 2011
I just checked in what I believe fixes the thread-safety problem with the InvocationManager put()/get(). I don't know if other thread-safety issues remain or not.
Cc:
codeto...@gmail.com
Feb 3, 2012
Maring fixed -- until someone can show me that it is not yet fixed.
Status:
Fixed
|
Owner: kandpwel...@gmail.com