Module return codes

[Alan DeKok]

Phil Mayers wrote:
> Where did we get with this? At the moment, I can't proceed with a
> migration to 3.x in the absence of last return code, and I don't want to
> use my local patch if it's not going upstream.

  I just merged it.

> It doesn't look easy to do this with an xlat; the "last" return code
> only exists as local variable(s) in modcall_* functions, so we'd need to
> grow the request object to store it. Even the highest-prio code only
> exists on the relevant modcall_stack_entry_t struct, and an xlat has no
> easy way to know the position in the modcall stack/tree.

  For 3.1, we'll add the modcall stack, and current stack index to the
REQUEST structure.  It's very useful to have it there.  It allows things
like proxying in a module, and then resumption from where it left off.

> I would appreciate a steer; we have serious problems with load spikes
> and time spent on this in 2.x is wasted IMO, so I need to get onto 3.x
> and then tackle the problem.

  Grab v3.0.x now, it has your patch.  The load spikes are a bit
different, of course.

  I suspect that 3.0 will have better debugging than 2.0.  You should
also be able to set triggers (SNMP or "exec") on certain events.  If
there isn't a trigger for an event you want, adding one is ~2 lines of code.

  Alan DeKok.