On Thursday, 23 September 2021 at 13:30:42 UTC, eugene wrote:

Actually in both cases it is MY+the compiler's code. A very similar example from C-land (without my digging up the exact details) is something like

for (int i = 0; i >= 0; i++) {
  // exit loop on signed integer overflow
}

where gcc 2.95 would do what "MY code" said, but later gcc versions would 'optimize' into an infinite loop (followed by dead code that can now be removed):

for (;;) {
  // never exit loop
}

Because in math, positive numbers never +1 into negative numbers. And in C this is undefined behavior which is (modern understanding:) complete license for the compiler to do anything at all. And on the specific architecture we are specifically compiling for there is specific behavior--but who cares about that, this is optimization! And if you complained about it, well you were a sloppy coder actually, for wanting the target architecture's actual behavior with your actual code as you actually wrote it. (If you feel like defending C's honor here, please, I've heard it already. Everybody thinks very highly of the nasal demons joke.)

There are other cases where very security-minded software had defensive code that an optimizer decided would never be needed, that then exposed a software vulnerability, or there are 'unnecessary' writes that are intended to remove a password from memory:

https://duckduckgo.com/?q=dead+code+elimination+security+vulnerability

On Thursday, 23 September 2021 at 14:00:30 UTC, eugene wrote:

void main(string[] args) {

    import core.memory : GC;

    auto Main = new Main();
    GC.addRoot(cast(void*)Main);
    Main.run();

    auto stopper = new Stopper();
    GC.addRoot(cast(void*)stopper);
    stopper.run();

Fine, works!

On Thursday, 23 September 2021 at 14:23:40 UTC, eugene wrote:

void main(string[] args) {

    import core.memory : GC;

    auto Main = new Main();
    GC.addRoot(cast(void*)Main);
    Main.run();

    auto stopper = new Stopper();
    GC.addRoot(cast(void*)stopper);
    stopper.run();

Nice. I thought of GC.addRoot several times but I was distracted by the general solution of using object lifetimes with it, so that a struct's destructor would call GC.removeRoot. For your case just pinning these and forgetting about them is the easiest way to do it.

On Monday, 13 September 2021 at 17:18:30 UTC, eugene wrote:

Now I guess, gdc optimization by size imply DSE.

On Thursday, 23 September 2021 at 14:31:34 UTC, jfondren wrote:

Yes, these two must live until the end of main().
Moreover, in real (C) programs I (usually) do
not create state machines on the fly,
instead I keep them in pools, like RX/TX machines pools
in echo-server and in echo-client.

On 9/23/21 10:55 AM, eugene wrote:

Technically, they should live past the end of main, because it's still possible to receive signals then.

But the chances of someone hitting ctrl-c in that window are quite small.

-Steve

On 9/23/21 9:18 AM, eugene wrote:

C# KeepAlive (and Go KeepAlive) are a mechanism to do exactly what you suggested -- use the object later.

However, they are recognized by the compiler as an intrinsic which generates no code or side effects, but is not subject to elimination by the optimizer.

See more details:

https://docs.microsoft.com/en-us/dotnet/api/system.gc.keepalive?view=net-5.0#remarks

-Steve

On Thursday, 23 September 2021 at 15:53:37 UTC, Steven Schveighoffer wrote:

No, as soon as an application get SIGTERM/SIGINT,
event queue is stopped and we do not need no
more notifications from OS (POLLIN/POLLOUT I mean).

Stopping event queue in this case is just
closing file descriptor obtained from epoll_create().
After this getting POLLIN from any fd (including signal fd) is
just impossible.

On Thursday, 23 September 2021 at 15:56:16 UTC, Steven Schveighoffer wrote:

"
This method references the obj parameter, making that object ineligible for garbage collection from the start of the routine to the point, in execution order, where this method is called. Code this method at the end, not the beginning, of the range of instructions where obj must be available.
"

Code this method at the end...

:)
it is the same as proposed by jfondren simple
writeln(stopper.sg0.number) in the end of main, right?

On 9/23/21 12:58 PM, eugene wrote:

Same effect, but writeln actually executes code to write data to the console, whereas KeepAlive doesn't do anything.

Essentially, you get the side effect of keeping the object as live, without paying the penalty of inserting frivolous code.

All my efforts to achieve the same via a library were thwarted by at least LDC (whose optimizer is very good).

The only possible solution I can think of is to generate an opaque function that LDC cannot see into, in order to force it to avoid inlining, and have that function do nothing.

However, there's always Link-Time-Optmization...

-Steve