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

That's not what is triggering the segfault though. The segfault is triggered by the signal handler referencing the destroyed object.

So imagine the sequence:

1. ctrl-c, signal handler triggers, shutting down the loop
2. main exits
3. GC finalizes all objects, including the Stopper and it's members
4. ctrl-c happens again, but you didn't unregister the signal handler, so it's run again, referencing the now-deleted object.
5. segfault

It's theoretically a very very small window.

-Steve

On Thursday, 23 September 2021 at 17:20:18 UTC, Steven Schveighoffer wrote:

With ease!

Just a note: there is no 'signal handler' in the program.
SIGINT/SIGTERM are blocked, notifications (POLLIN) are received via epoll_wait().

Probably, a destructor for Signal class should be added, in which

• close fd, obtained from signalfd()
• unblock the signal (thus default signal handler is back again)

At this point we have default signal handler

But even without destructor, no segfault will happen,
because there is no signal handler

On Thursday, 23 September 2021 at 17:20:18 UTC, Steven Schveighoffer wrote:

but both SIGINT and SIGTERM are still blocked,
they just will not reach the process.

On Thursday, 23 September 2021 at 17:49:43 UTC, eugene wrote:

oops..

closing epoll fd should be moved from EventQueue dtor to stop() method,
then everything will be Ok.

On Thursday, 23 September 2021 at 17:53:00 UTC, eugene wrote:

no oops, that's all right.

• when creating Signal instance, corresponding signal becames blocked

final class Signal : EventSource {

    enum int sigInt = SIGINT;
    enum int sigTerm = SIGTERM;
    ulong number;

    this(int signo) {
        super('S');

        sigset_t sset;
        sigset_t old_sset;
        /* block the signal */
        sigemptyset(&sset);
        sigaddset(&sset, signo);
        sigprocmask(SIG_BLOCK, &sset, &old_sset);

        id = signalfd(-1, &sset, SFD_CLOEXEC);

• upon receiving SIGINT stopperIdleS0() is called.
  now stop variable of EventQueue is false

• next call to wait() method just return.
  (remember, signals are still blocked)

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

void keepAlive(Object o) {
}

void main(string[] args) {

    import core.memory : GC;

    auto Main = new Main();
    Main.run();

    auto stopper = new Stopper();
    stopper.run();

    writeln(" === Hello, world! === ");
    auto md = new MessageDispatcher();
    md.loop();

    keepAlive(Main);
    keepAlive(stopper);

    writeln(" === Goodbye, world! === ");
}

works ok with dmd, stopper is not collected.

On 9/23/21 2:18 PM, eugene wrote:

void keepAlive(Object o) {
}

void main(string[] args) {

     import core.memory : GC;

     auto Main = new Main();
     Main.run();

     auto stopper = new Stopper();
     stopper.run();

     writeln(" === Hello, world! === ");
     auto md = new MessageDispatcher();
     md.loop();

     keepAlive(Main);
     keepAlive(stopper);

     writeln(" === Goodbye, world! === ");
}

With dmd -O -inline, there is a chance it will be collected. Inlining is key here.

-Steve

On Thursday, 23 September 2021 at 18:43:36 UTC, Steven Schveighoffer wrote:

never mind, GC.addRoot() looks more trustworthy, anyway :)

On 9/23/21 1:44 PM, eugene wrote:

Oh interesting! I didn't read the code closely enough.

Yes, I would recommend that. Always good for a destructor to clean up any non-GC resources that haven't already been cleaned up. That's actually what class destructors are for.

So it gets written to the file descriptor instead? And nobody is there reading it, so it's just closed along with the process?

I've not done signals this way, it seems pretty clever and less prone to asynchronous issues.

-Steve

On Thursday, 23 September 2021 at 18:53:25 UTC, Steven Schveighoffer wrote:

"everything in Unix is a file" (c)

All event sources (sockets, timers, signal, file system events)
can be 'routed' through i/o multiplexing facilities, like
select/poll(posix)/epoll(linux)/queue(freebsd) etc.

No, destructors are not necessary, since after SIGINT/SIRTERM
program is about to terminate and all resources will be
released anyway.

In C I do same way - do not close fd, which live from
start to end, do not free() pointers and so on, no need.

When signal happens (or timer expires, or file is deleted)
process get EPOLLIN on corresponding file descriptor
via epoll_wait() and then process has to read some info
from these file descriptors.

Yes, as any other file descriptor.

It's just great, thanks to Linux kernel developers.
Look in to engine dir in the source.

C (more elaborated) variant:
http://zed.karelia.ru/mmedia/bin/edsm-g2-rev-h.tar.gz