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
