Re: [scope] scope_fail is unimplementable

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2023-04-09 00:16:38

niedz., 9 kwi 2023 o 00:28 Andrey Semashev via Boost <boost_at_[hidden]>
napisał(a):

> On 4/7/23 18:42, Andrey Semashev wrote:
> > On 4/7/23 15:55, Andrzej Krzemienski wrote:
> >> czw., 6 kwi 2023 o 23:51 Andrey Semashev via Boost
> >> <boost_at_[hidden] <mailto:boost_at_[hidden]>> napisał(a):
> >>
> >>     Thus I
> >>     wouldn't say scope_success/scope_fail are unimplementable - they
> clearly
> >>     are - but that they are incompatible with coroutines. That is, these
> >>     scope guards will work as expected as long as you don't switch
> >>     coroutines within the guarded scope.
> >>
> >> Maybe this is just a question of the choice of words.
> >> But the docs do not present the situation in this way.
> >>
> >> "Although it is possible to specify arbitrary condition function
> >> objects, typically |scope_success
> >> <
> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_success.html>|
> invokes its action when the scope is left normally (i.e. not via an
> exception) and |scope_fail <
> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail.html>|
> should typically be used to handle errors, including exceptions."
> >>
> >> This guarantee (when scope is exited not normally) cannot be satisfied
> >> in general. One cannot use it in a coroutine: directly or indirectly.
> >> One might not even know the context.
> >>
> >> "By default, |scope_success
> >> <
> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_success.html>|
> will invoke its action if it is destroyed normally, |scope_fail <
> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail.html>|
> - if it is destroyed due to an exception being thrown."
> >
> > Note the "typically". :) In this documentation I tried to describe these
> > facilities in more or less simple language, describing the most typical
> > use cases. For this simplicity, I had to omit some formalities and
> > corner cases that would detract the reader from the main purpose and
> > intended use case of the components. Perhaps, I should improve the
> > wording, but I would still like the docs to be easily readable.
> >
> > And, as I admitted earlier, I completely forgot about coroutines. I will
> > add a note about coroutenes in relation to the default failure condition
> > used by scope_success/scope_fail.
> >
> >> (BTW, The synopsis in
> >>
> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail.html
> <
> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail.html
> >
> >> does not indicate that there is any default Cond.)
> >
> > Hmm, for some reason Doxygen removed the default template arguments for
> > scope_success/scope_fail. I'll see if I can fix this. Thanks for
> noticing.
>
> I have updated the docs to fix those issues and added the note re.
> coroutines. I've also improved wording so that the general discussion
> does not focus on exceptions as much but rather failure and non-failure
> conditions.
>

Thanks.

Well, in my experience, the scope fail/success is exclusively about
exceptions, so I will still focus on exceptions.
Here is a small benchmark comparing the deactivation-based mechanism of a
scope_guard with uncaught_exception-based mechanism of scope_fail.
The former performed like 36 times faster, as it doesn't have to perform
the calls to the runtime.

Regarding failure conditions other than exceptions, the problem with
coroutines may still appear if a thread-local storage is used, such as
errno.

Regards,
&rzej;

>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>