Hi there,
I'm reading the source code of unbound to see if I can write my own
module who does similar things to your pymod.
When I'm managing to know what should I do in inform_super callback, I
find that there are two situations it will be called:
a) qstate finished, the inform_super of module 0 will be called
b) qstates kicked out by mesh_make_new_space(), mesh_walk_super()
calls the inform_super of s->curmod
Could anybody tell me what should I do in inform_super in the second case?
Hi Yang,
Thanks for your response. I'm sorry that I must make an explaination
my question to make it clear.
What I really concern is that: firstly, if my mod_id is 1, s.curmod is
2, mine inform_super won't be called; secondly, if mine inform_super
is called, what about module 0's inform_super()?
For example, if the order of the module is "validator mine iterator",
the qstate is going to be deleted when curmod is 2, then I may lose
something because mine module lost its chance to inform_super().
Another example: If s->curmod is 1, a.k.a my module, then the super
state's validator may lose something if my inform_super() only play
with its own business.
For example, if the order of the module is "validator mine iterator",
the qstate is going to be deleted when curmod is 2, then I may lose
something because mine module lost its chance to inform_super().
Sorry in this case I should remove validator from the module list,
curmod is still the iterator. According to my current understanding on
the source codes. inform_super() is only meaningful if the module
chould be set as the first module.
Hi Yang,
For example, if the order of the module is "validator mine iterator",
the qstate is going to be deleted when curmod is 2, then I may lose
something because mine module lost its chance to inform_super().Sorry in this case I should remove validator from the module list,
curmod is still the iterator. According to my current understanding on
the source codes. inform_super() is only meaningful if the module
chould be set as the first module.
So, for the people on the bench here, this is about the internal modules
that unbound uses to resolve queries. They are event driven. The
inform_supers event happens if a sub-query is done. For example, the
DNSKEY for a trust anchor has been looked up and the query can continue
its validation.
A module creates a subquery, and then waits for that to be done. This
event is the inform_supers event. It happens for the module that is
active (i.e. that created the subquery).
The same mechanism is also used for network access. The module creates
a network-query. An event arrives when that is done, it is sent to the
active module (i.e. that created the network query and then waited for it).
Best regards,
Wouter
Hi Wijngaards,
I understand and also read the code of the event-driven model of
unbound. I'm wondering that is it a bug in mesh_walk_supers(), only
the current module's inform_super() function is called. Why not all
the modules' inform_super() are called or only the first module's
inform_super() is called.
While I'm typing I realized that I misread this line of the code of
mesh_walk_supers()
(*mesh->mods.mod[ref->s->s.curmod]->inform_super)(&mstate->s,
ref->s->s.curmod, &ref->s->s);
the inform_super being called is the super states's current module,
not the child's.
Sorry for my carelessness. Thank you for your help. I have the answer now.
By the way I suggested that it's better either add a comment on
inform_super or change its name to a passive form to prevent people
misunderstand the action of the function.