On Sunday, 3 December 2017 at 02:56:38 UTC, H. S. Teoh wrote:
Ha! I've been using Linux for decades now and this is the first
time I'm aware of this function. Should simplify my code when
I'm not planning to be Posix-portable. Thanks!
In the same vein, make sure you read about timerfd and eve
On Sat, Dec 02, 2017 at 11:32:17AM +, Patrick Schluter via
Digitalmars-d-learn wrote:
> On Saturday, 2 December 2017 at 04:49:26 UTC, H. S. Teoh wrote:
> > On Sat, Dec 02, 2017 at 04:38:29AM +, Adam D. Ruppe via
> > Digitalmars-d-learn wrote:
> > > [...]
> >
> > Signal handlers can potent
On Saturday, 2 December 2017 at 04:49:26 UTC, H. S. Teoh wrote:
On Sat, Dec 02, 2017 at 04:38:29AM +, Adam D. Ruppe via
Digitalmars-d-learn wrote:
[...]
Signal handlers can potentially be invoked while inside a
non-reentrant libc or OS function, so trying to do anything
that (indirectly
On 2017-12-02 02:26, Adam D. Ruppe wrote:
But this is intentional - there is no generic, reliable, cross-platform
way of handling it natively. So you need to know the system and code it
yourself. Not super hard but does take a bit of effort in your code.
Since the "scope" block is not execute
On Saturday, 2 December 2017 at 04:28:57 UTC, Wanderer wrote:
Thanks! This works. But it seems a little bit suspicions that
D's type for handler function has `nothrow` `@nogc` and
`@system`. I wonder why is that?
During execution of that handler, it make sense to prohibit the
allocation of an
On Sat, Dec 02, 2017 at 04:38:29AM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Saturday, 2 December 2017 at 04:28:57 UTC, Wanderer wrote:
> > Thanks! This works. But it seems a little bit suspicions that D's
> > type for handler function has `nothrow` `@nogc` and `@system`. I
> > wond
On Saturday, 2 December 2017 at 04:28:57 UTC, Wanderer wrote:
Thanks! This works. But it seems a little bit suspicions that
D's type for handler function has `nothrow` `@nogc` and
`@system`. I wonder why is that?
Signal handlers are ridiculously limited in what they are allowed
to do. Really,
On Saturday, 2 December 2017 at 03:52:19 UTC, codephantom wrote:
On Saturday, 2 December 2017 at 00:41:19 UTC, Wanderer wrote:
Is there any method to cleanup on Ctrl-C?
// --
import std.stdio;
import core.thread;
extern(C) void signal(int sig, void function(int
On Saturday, 2 December 2017 at 01:26:14 UTC, Adam D. Ruppe wrote:
On Saturday, 2 December 2017 at 00:41:19 UTC, Wanderer wrote:
I wonder why `scope(exit)` code is not executed when the
program is terminated with Ctrl-C.
It depends on what your operating system is. On win32, I
believe it does
On Saturday, 2 December 2017 at 00:41:19 UTC, Wanderer wrote:
Is there any method to cleanup on Ctrl-C?
// --
import std.stdio;
import core.thread;
extern(C) void signal(int sig, void function(int));
extern(C) void exit(int exit_val);
extern(C) void handle(int
On Saturday, 2 December 2017 at 00:41:19 UTC, Wanderer wrote:
I wonder why `scope(exit)` code is not executed when the
program is terminated with Ctrl-C.
Which OS?
For example:
```
import std.stdio;
import core.thread;
void main()
{
scope (exit)
{
writeln("Cleanup");
}
On Saturday, 2 December 2017 at 00:41:19 UTC, Wanderer wrote:
I wonder why `scope(exit)` code is not executed when the
program is terminated with Ctrl-C.
It depends on what your operating system is. On win32, I believe
it does run. On Linux (and I think Mac) you need to set a signal
handler t
On 12/01/2017 04:41 PM, Wanderer wrote:
I wonder why `scope(exit)` code is not executed when the program is
terminated with Ctrl-C.
For example:
```
import std.stdio;
import core.thread;
void main()
{
scope (exit)
{
writeln("Cleanup");
}
writeln("Waiting...");
I wonder why `scope(exit)` code is not executed when the program
is terminated with Ctrl-C.
For example:
```
import std.stdio;
import core.thread;
void main()
{
scope (exit)
{
writeln("Cleanup");
}
writeln("Waiting...");
Thread.sleep(10.seconds);
writeln("Done w
14 matches
Mail list logo
