3 ms·

And you guarantee you can release those resources with out error or exception all the time? If this is not the case then a destructor is the wrong place to be

And you guarantee you can release those resources with out error or exception all the time? If this is not the case then a destructor is the wrong place to be doing this work anyways. If an external service requires a client experiencing an error to manually release resources than that external service has significant design or protocol issues.

ignoramous 2y ago
> guarantee you can release those resources with out error or exception all the time releasing resources (optimally) and resource exhaustion / ageing (crash recovery) are orthogonal. > a destructor is the wrong place I commented on GP's use of exit() not on finalizers / destructors. > If an external service requires a client experiencing an error to manually release resources... You perhaps missed what I wrote: It isn't optimal, if a failing client never signals release (think: distributed lock).
- akira2501 2y ago
  > releasing resources (optimally) and resource exhaustion / ageing (crash recovery) are orthogonal. In concept. In the reality of implementation they are not. > I commented on GP's use of exit() not on finalizers / destructors. You said they were "suboptimal." Implying there is an available optimal solution. I'm challenging that exact notion. > It isn't optimal, You perhaps missed the point. It _can't_ possibly be optimal given the nature of the problem itself. These are the wrong terms to understand the problem in.
  - ignoramous 2y ago
    > In concept. In the reality of implementation they are not. Recovery flows are very different in both concept and implementation. > It can't possibly be optimal given the nature of the problem itself. What's in the "nature" of this problem that one should never bother releasing resources once done? I mean, if any program creates an external resource (say, unix domain socket or shared mem), it isn't okay if it never releases it.

ignoramous 2y ago

> guarantee you can release those resources with out error or exception all the time releasing resources (optimally) and resource exhaustion / ageing (crash recovery) are orthogonal. > a destructor is the wrong place I commented on GP's use of exit() not on finalizers / destructors. > If an external service requires a client experiencing an error to manually release resources... You perhaps missed what I wrote: It isn't optimal, if a failing client never signals release (think: distributed lock).

akira2501 2y ago
> releasing resources (optimally) and resource exhaustion / ageing (crash recovery) are orthogonal. In concept. In the reality of implementation they are not. > I commented on GP's use of exit() not on finalizers / destructors. You said they were "suboptimal." Implying there is an available optimal solution. I'm challenging that exact notion. > It isn't optimal, You perhaps missed the point. It _can't_ possibly be optimal given the nature of the problem itself. These are the wrong terms to understand the problem in.
- ignoramous 2y ago
  > In concept. In the reality of implementation they are not. Recovery flows are very different in both concept and implementation. > It can't possibly be optimal given the nature of the problem itself. What's in the "nature" of this problem that one should never bother releasing resources once done? I mean, if any program creates an external resource (say, unix domain socket or shared mem), it isn't okay if it never releases it.