On 1/20/2012 3:05 PM, Olemis Lang wrote:
> On Fri, Jan 20, 2012 at 2:58 AM, Jun Omae<jun6...@gmail.com> wrote:
>> Hi,
>>
>
> :)
>
>> On Fri, Jan 20, 2012 at 00:44, Olemis Lang<ole...@gmail.com> wrote:
>>> I'm writing a patch containing a unit test with a simplified scenario
>>> illustrating the barely minimal context for this to happen . The root
>>> cause for infinite loop is that after r10295 instances are registered
>>> in ComponentManager's «pool» after calling __init__ method (#9418
>>> records the whole discussion ;)
>>
>> I can reproduce the issue and understand the condition. During a
>> component is initializing, accessing extension points of the component
>> causes infinite loop.
>>
>
> yep
And this is an error. A component constructor is called in a
special way, as you've found out, and it should really do pretty
much nothing. Example of valid use is to set a list to [], a
hash to {}, or such. In trunk you could even use @lazy
(http://trac.edgewall.org/changeset/10737) to help with such
things. So doing anything lengthy is prohibited and the same
for "re-entering" the component machinery.
This is documented:
http://www.edgewall.org/docs/trac-trunk/html/api/trac_core.html#more-on-components
Well, I could add a more specific note about the temptation to
access the extension points from there, as apparently it's not
implicit.
>
>> Solution 1.
>> Detect and refuse accessing the extension points during initializing
>> at `ExtensionPoint.extensions`.
>>
> [...]
Either this, or leave things as they are.
>
> -1 ... as this kind of situations are used by components providing
> default implementations for a given interface .
Simply set some flag and do the initialization *later* when
needed (well, you should also possibly need a lock but I won't
get into this now - simply look at the various examples in the
Trac code itself).
>
>>
>> Solution 2.
>> When detecting accessing the extension points, use `component` variable
>> instead of `component.compmgr[cls]` at `ExtensionPoint.extensions`.
>>
No, this would present a misleading list, and moreover give the
impression that it's OK to do such things.
>
> Solution solution 3 is available ... it allows to do things as usual
> by skipping silently nested calls to __init__ .
> It comes in the form of two patches
>
> 1- adds a test case to detect this [1]_
> 2- on top of 1 includes solution 3 to the problem i.e. infinite
> recursion loop [7]_
>
A bit too complex for this corner case, no? Perhaps if that would
have been a legit corner case, but it's not.
-- Christian
> .. [7] Patch 2 Skipping nested calls to __init__
>
(https://bitbucket.org/olemis/trac-mq/src/fa0fcf0f1c3f/tho/themeengine/t-9580-infinite-recursion.diff)
>
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to trac-dev@googlegroups.com.
To unsubscribe from this group, send email to
trac-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
