On Fri, 2018-02-02 at 20:14 +, 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 EINT
On Thu, 2018-02-01 at 20:13 +, 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:
On Fri, 2018-02-02 at 01:09 +, David Nadlinger via Digitalmars-d-
learn wrote:
> On Thursday, 1 February 2018 at 11:42:32 UTC, Russel Winder wrote:
> > The problem is actually a thread blocked in an inotify blocking
> > read. As both Steven and yourself have pointed out I am going
> > to have
On Thursday, 1 February 2018 at 11:42:32 UTC, Russel Winder wrote:
The problem is actually a thread blocked in an inotify blocking
read. As both Steven and yourself have pointed out I am going
to have to use a timeout to check the state of the application.
There are better solutions (select/..
On Thursday, 1 February 2018 at 12:30:24 UTC, Russel Winder wrote:
On Thu, 2018-02-01 at 12:15 +, 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
On Thu, 2018-02-01 at 12:15 +, 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 b
On Thursday, 1 February 2018 at 11:42:32 UTC, Russel Winder wrote:
On Wed, 2018-01-31 at 22:15 +, Arek via Digitalmars-d-learn
wrote:
[…]
The problem is actually a thread blocked in an inotify blocking
read. As both Steven and yourself have pointed out I am going
to have to use a timeou
On Wed, 2018-01-31 at 22:15 +, Arek via Digitalmars-d-learn wrote:
>
[…]
> Assuming your're talking about threads: there's no secure method
> of forcing the thread to stop. Threads share the state (eg. can
> hold the locks) and killing them is always risky.
I am indeed talking threads not O
On Wed, 2018-01-31 at 13:26 -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:
>
[…]
> You talking about processes or threads? `receive` I believe is an
> inter-thread channel, no?
These are threads with no shared memory, just message passing via
channels. I think of them as processes, b
On Wednesday, 31 January 2018 at 17:44:37 UTC, Russel Winder
wrote:
So, I have an application which has a sort of nano-services
architecture, basically it is a set of communicating processes.
Terminating those processes blocked on an input channel is
quite easy, send a terminate message on the
On 1/31/18 12:44 PM, Russel Winder wrote:
So, I have an application which has a sort of nano-services
architecture, basically it is a set of communicating processes.
Terminating those processes blocked on an input channel is quite easy,
send a terminate message on the input channel. But what abou
So, I have an application which has a sort of nano-services
architecture, basically it is a set of communicating processes.
Terminating those processes blocked on an input channel is quite easy,
send a terminate message on the input channel. But what about a process
that has no input channel, one t
12 matches
Mail list logo
