3 ms·

One of my favorite hacky workarounds is to simply call _exit(0) for an immediate exit without running destructors. Most of the time, the destructors are just fr

by kccqzy 2y ago

One of my favorite hacky workarounds is to simply call _exit(0) for an immediate exit without running destructors. Most of the time, the destructors are just freeing memory that will be reclaimed by the OS anyways so they are not worth running if you know the program is exiting. And even if the destructor does more than just freeing memory, maybe the work it's doing isn't needed if you know the process is ending soon: maybe it's joining threads or releasing mutexes or deleting timers. You will find that in a typical C++ codebase, the destructors that do useful things (say, flushing useful buffers and closing files etc) are much fewer.

ignoramous 2y ago
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.

by kccqzy 2y ago

ignoramous 2y ago

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.