Re: scope(exit) and Ctrl-C
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));
extern(C) void exit(int exit_val);
extern(C) void handle(int sig)
{
writeln("Control-C was pressed..aborting
programgoodbye...");
// do more stuff?
exit(-1);
}
void main()
{
enum SIGINT = 2;
signal(SIGINT,);
scope (exit){ writeln("Cleanup"); }
writeln("Waiting...");
Thread.sleep(10.seconds);
writeln("Done waiting...");
}
// -
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?
Re: scope(exit) and Ctrl-C
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 run. On Linux (and I think Mac) you need to set a signal handler to catch the ctrl c. 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. On Windows 10 it does not run. Thanks for the info, I dig around and truly there's no "general" way to do this.
scope(exit) and Ctrl-C
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 waiting...");
}
```
If I wait 10 seconds, I get "Cleanup" output.
But if I use Ctrl-C to terminate the program before 10 seconds
elapse, there's no "Cleanup" output.
Is it intentional?
Is there any method to cleanup on Ctrl-C?
Re: Shared and race conditions
On Wednesday, 29 November 2017 at 17:03:42 UTC, Steven Schveighoffer wrote: On 11/29/17 11:13 AM, Wanderer wrote: I'm trying to simulate a race condition in D with the following code: (https://run.dlang.io/is/RfOX0I) One word of caution, I think the running of your code on run.dlang.io is cached. Refreshing doesn't make it re-run. https://run.dlang.io/is/k0LhQA -Steve I was using this just for the reference, as I've noticed caching as well. Thanks Steve, for spending time and actually hitting a race!
Re: Shared and race conditions
On Wednesday, 29 November 2017 at 16:33:50 UTC, Steven Schveighoffer wrote: On 11/29/17 11:13 AM, Wanderer wrote: [...] [snip] [...] Using the compiler switch -vcg-ast, I see no synchronization of these methods. [...] That's what I assume, I was just lucky not to see a race. Thanks for `-vcg-ast` switch! Really helpful, and it answered my questions as no syncronization code was added.
Re: Shared and race conditions
On Wednesday, 29 November 2017 at 16:19:05 UTC, Michael wrote: On Wednesday, 29 November 2017 at 16:13:13 UTC, Wanderer wrote: [...] I unfortunately cannot answer your question but I am noticing that running the code with DMD gives you an unordered sequence of IDs, but running with DMD-nightly gives you a sequence in the correct order. I wonder what has changed to do with threads that causes this difference between compiler versions. The "unordered" output is completely fine, as I assume runtime does not guarantee the order of execution of logical threads (order is different between ldc and dmd as well).
Shared and race conditions
I'm trying to simulate a race condition in D with the following
code:
(https://run.dlang.io/is/RfOX0I)
```
import std.stdio;
import core.thread;
import std.concurrency;
shared struct IdGen(T)
{
T id;
this(T start)
{
id = start;
}
T next()
{
id = id.next();
return id;
}
}
struct MyId
{
uint num;
shared MyId next()
{
return MyId(num + 1);
}
}
static void getId(shared IdGen!(MyId)* g)
{
writeln("next: ", g.next());
writeln("next: ", g.next());
}
void main()
{
MyId start = {0};
auto g = IdGen!(MyId)(start);
auto num = 12;
for (auto i = 0; i < num; i++)
{
spawn(, );
}
thread_joinAll();
writeln("Done");
}
```
But all I get is correct IDs without any sign of a race (i.e.
duplicate ids).
Does compiler add synchronization for `shared` data?
Re: floating point conversion
The General rule is not to compare floats for equality, (is 0.0==-0.0, etc.). Use a epsilon based comparision scheme instead or a wrapper around it. That's not exactly true. You cannot (and should not) compare floating points for equality, and use epsilon-based comparison instead, only in one certain case: when one of the arguments if the result of computation, during which a computational error might accumulate. If you have two exact or constant values, comparing them directly is perfectly fine. :-) Nowadays floating-point hardware support is not that buggy.
Re: Different random shuffles generated when compiled with gdc than with dmd
I must note if the sequence is predictable, it's not random anymore, it's pseudo-random at most. Also, if anyone interested, PHP had such way to generate predictable sequences in the past, but after it was horribly misused by various people for crypto keys/password generation purposes, they have forbidden it completely, so only non-predictable sequences in PHP from now on. Maybe, just maybe, it makes sense not to stand on the same rack twice.
Re: std.algorithm range violation
On Wednesday, 28 May 2014 at 10:10:41 UTC, maarten van damme via Digitalmars-d-learn wrote: an anyone explain me what I'm doing wrong here : [code] dstring[][dstring] providor_symbol_map; ... writeln(providor_symbol_map.keys.sort!((x,y)=providor_symbol_map[x].length=providor_symbol_map[y].length)); [/code] output: core.exception.RangeError@std.algorithm(9429): Range violation dstring[][dstring] declaration looks a bit obscure to me... what do you intent with it, array of maps or map of arrays? Also, it looks unnatural that inside sorting lambda, you refer outside from it (back to providor_symbol_map variable). Ideally, you should only use variables x and y. Does D support sorting by map entries instead of by keys only or by values only?
Re: std.algorithm range violation
Sorry about typo, I meant
providor_symbol_map.sort!((x,y)={x.value.lengthy.value.length})
above.
Re: std.algorithm range violation
Aha, so you want to maintain spam word - set of senders
relationship, so it's actually map of sets and your declaration
is correct. You only need to sort map's entries (key and value
pairs together).
If D supports that, it should be something like
providor_symbol_map.sort!((x,y)={x.value.length=y.value.length}),
but I'm not sure it would work...
But I'm just learning D (and very much like it so far!),
hopefully someone more skilled will reply as well. :-)
