4 ms·

Sub-optimal if the exiting process must relinquish resources external to the current process or the host.

by ignoramous 2y ago

gpderetta 2y ago
Optimal of you are writing crash-only, i.e. reliable, software.
- TeMPOraL 2y ago
  Suboptimal if you're relying on RAII not for "regular" resources, but more abstract ones like "correctly bookended piece of persisted data". Then again, I guess it's optimal if you're writing fault-resistant software.
akira2501 2y ago
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.

Sub-optimal if the exiting process must relinquish resources external to the current process or the host.

gpderetta 2y ago

Optimal of you are writing crash-only, i.e. reliable, software.

TeMPOraL 2y ago
Suboptimal if you're relying on RAII not for "regular" resources, but more abstract ones like "correctly bookended piece of persisted data". Then again, I guess it's optimal if you're writing fault-resistant software.

akira2501 2y ago

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.