Program crash: GC destroys an object unexpectedly

[eugene]

On Thursday, 23 September 2021 at 18:53:25 UTC, Steven 
Schveighoffer wrote:
> On 9/23/21 1:44 PM, eugene wrote:
>> Just a note: there is no 'signal handler' in the program.
>> SIGINT/SIGTERM are **blocked**, notifications (POLLIN) are 
>> received via epoll_wait().
>
> Oh interesting! I didn't read the code closely enough.

"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.

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

> 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.

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.

> So it gets written to the file descriptor instead?

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.

> And nobody is there reading it, so it's just closed along with 
> the process?

Yes, as any other file descriptor.

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

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