On Thursday, 1 February 2018 at 12:30:24 UTC, Russel Winder wrote:
On Thu, 2018-02-01 at 12:15 +0000, Arek via Digitalmars-d-learn
wrote:
[…]
Try to use inotify in non-blocking mode (an example here:
https://gist.github.com/pkrnjevic/6016356) with select or
epoll and timeouts.
Isn't there a C++ binding for the C API?
I am using DInotify which is a D binding. I will be checking
soon but I am assuming there is a timeout version so I can loop
to check the application state.
DInitify doesn't cover full capabilities of the inotify API.
Especially it doesn't utilize newer inotify_init1 syscall and
doesn't expose 'select' interface.
This C++ wrapper may be interesting for you:
https://github.com/erikzenker/inotify-cpp
But I haven't used it.
I would use shared memory here (eg. atomic bool) because any
communication channel introduces possibility of further
blocking problems.
A priori I am not convinced. I have used a state variable in
C++ and Python code where there is no channel system, but in
Go, Groovy/GPars, using channels is always preferable. Given
the channel has a "read if there is something to read" there
can't be a blocking problem – if the channel system is a good
one.
You may be right. But interrupting the thread is very low level
mechanism.
Eg in Java, it is incorporated into Thread class: thread has
method 'interrupt()' which
sets the flag, and there is property 'isInterrupted()'. Usually
your thread code have something like
while(!Thread.currentThread().isInterrupted()) { /* do
something*/ }
I would use similar pattern.
Arek
