On Thu, 2018-02-01 at 20:13 +0000, Arek via Digitalmars-d-learn wrote:
> 
[…]
> 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.

Hummm… sounds like I need to look to create a pull request to get to dinotify 0.2.3 or even 0.3.0.

> > > 
[…]
> 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.

I do want to avoid such low-level things, they may be required for building libraries, but they seem totally the wrong level of concept for an application.

I am definitely headed to the (select|poll|epoll) on the inotify file descriptor to get the timeout, and then either read or check the input channel for termination or an atomic Boolean state variable. Channels seem most likely since parent threads send a terminating token.


-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Fri, 2018-02-02 at 20:14 +0000, David Nadlinger wrote:
> 
[…]
> That sounds entirely sensible. Your original question was whether it
> was
> possible to terminate threads blocked in a syscall, though. Signals
> allow you to do that on POSIX for many "slow" syscalls, by making it
> return EINTR. You would check whatever channel/atomic flag/…
> mechanism
> you use to signal termination before continuing to block by
> reissuing
> the syscall.
> 
> I haven't tested how `read` behaves for inotify myself, but
> inotify(7)
> suggests that it indeed handles signals this way.
[…]

After some discussions, Dmitry acted very quickly and added a timeout read to the blocking read in dinotify.

This solves my problem "at a stroke" as I can now block waiting for a specific time on inotify and then check the input channel for a time and repeat. Not really busy wait just a sequence of blocking reads with timeouts. The important thing is that With very little latency, the thread is checking two things.

DInotify 0.3.0 will likely appear soon in Dub. It would be good to get it packaged for Debian. I will take up an invitation to submit a ready made package for the Debian D packaging team.


-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk