[Rake-devel] Rake circular dependency patch
schapht at gmail.com
Mon Jun 18 09:41:28 EDT 2007
(Note, side Assaf is the original author here, I've CC'd him on this
as well. Assaf, let me know if you're on the ML already)
On Jun 18, 2007, at 8:39 AM, Jim Weirich wrote:
> (1) I am uncomfortable with the use of the Thread.current hash.
> The thread current hash is essentially a global variable, and I
> have already moved a number of global resources into the
> Rake::Application object in previous release cycles. The current
> circ-dep implementation is thread safe, but does not support
> multiple applications. However, the only time that would be a
> problem is if one application object invoked tasks in a different
> application object within the same thread. This is such a small
> edgecase that I'm trying to decide if I'm being unreasonable in my
> discomfort. Feedback is welcome.
While I'm not one for over-optimization, it seems like satisfying
this would come down to keeping the stack in a Rake::Application
hash, keyed on the current thread. If so, it doesn't sound like it'd
be difficult to add.
> (2) I'm wondering about a stack implementation that might be
> inherently thread safe in that it is never modified. If you kept a
> linked list chain of previous task invokers and only added yourself
> to the head of the list. The list itself is never modified and each
> task invocation (not each task object) must keep a reference to the
> head of its own list. For this to work, I'm thinking that the
> chain of previous task invocations must be passed as an argument to
> each call to invoke. Since existing (non-rake) software tends to
> call invoke for their own purposes, I'm not sure how this can be
> done without breaking backwards compatibility. Again, feedback is
> welcome on this item.
Sounds like (1) is the safer option here. I don't get the feeling
this sort of check is worth breaking backwards compatibility. But I
like the concept of inherently thread-safe data structures.
More information about the Rake-devel