Re: stp_exit change

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

> > > [...]
> > > int get_value() {
> > >    ...
> > >    if (something really bad and unexpected happens) {
> > > 	stp_error("bad mojo")
> > > 	return 0;
> > >    }
> > >    return val;
> > > }
> > > [...]
> > 
> > What are some existing examples of this?  How is the caller supposed
> > to know that something "fatal" occurred if not by rc?

> One example, is all the map sets.
>   _stp_map_set_isi (global_x, l->__tmp6, l->__tmp7, l->__tmp9);

My question was about code *within the runtime* that wanted to call
stp_error, so this is not an example of that.

This is code generated by the translator, and it fails to check an
existing return code.  I think this used to work, sigh.

>   rc = _stp_map_set_isi (global_x, l->__tmp6, l->__tmp7, l->__tmp9);
>   if (rc) {
>     atomic_set (&session_state, STAP_SESSION_ERROR);
>     if (rc == -1)
>         _stp_error("map overflow at %s\n", probe_point);
>     else
>         _stp_error("internal error: bad args to _stp_map_set\n");
>     goto out;
>   }

That is not how the translator models errors within ordinary
statements.  Instead, it sets the context's "last_error" pointer, and
does a goto to the appropriate unwinding label.  This allows
consistent error reporting, and association with the script site.


> This will not help our compile times or performance and it will have
> no advantage over letting the runtime directly call
> stp_error(). [...]

That would presume that the runtime has enough information about the
context and the intentions of the user - something that's not true
e.g. with the "soft error" concept.  It also mixes policy and
mechanism concepts.


- FChE