Hello,
Aleksei Preobrazhenskii found a bug that causes GC deadlock and
offered a bug fix. I can confirm the bug. Hope the bug fix will
be implemented in the next release.
https://issues.dlang.org/show_bug.cgi?id=15939
Best regards,
Ilya
comfortably in the handler.
>
> I wish there was a more direct way to do this. Signals are a bread and
> butter aspect of the Linux architecture. I guess mangling is at the
> root of the problem.
>
> Thank you.
if you are on GNU/Linux, you can use `signalfd` to integrate s
On Wednesday, 27 May 2015 at 13:52:33 UTC, Robbin wrote:
I'm writing a daemon in D on linux. I need to be able to stop
(kill) it. The traditional C method is a signal handler. I can
do this, but I can't figure out how to get the handler to do
anything to tell the rest of the daemon to quit.
icate when it is time to
die. In the signal handler I can send a message and in the
class, send a std.signal to end the thread and then clean up the
main loop and exit. nn_poll is a c routine, so I should work
comfortably in the handler.
I wish there was a more direct way to do this. Sig
The way I do it is to set a global variable in the signal
handler, then have the loop watch for it. So like
__gshared bool terminated = false;
extern(C) void handleSigTerm(int) { terminated = true; }
void main() {
while(!terminated) {
if(select() < 0)
if(errno == EINT
I'm writing a daemon in D on linux. I need to be able to stop
(kill) it. The traditional C method is a signal handler. I can
do this, but I can't figure out how to get the handler to do
anything to tell the rest of the daemon to quit.
In a C++ handler, I closed the files that were open, remo
On Thursday, 10 July 2014 at 20:20:41 UTC, Sean Kelly wrote:
Not currently. Mostly because you're the first person to run
into this issue (or at least to ask about it, as far as I can
recall). Using signals for collection at all is a real sore
point for me--I think it's a te
relatively rare but
non-zero use of SIGUSR1/SIGUSR2 in the code base will, due to
murphy's law bound to trip something up and put people in a
position of having a confusing and difficult to debug issue.
Fortunately we _do_ have a centralized "allocator" for Posix
realtime signals. I
will, due to murphy's law
bound to trip something up and put people in a position of having
a confusing and difficult to debug issue. Fortunately we _do_
have a centralized "allocator" for Posix realtime signals. I was
thinking of adding a int rt_init2(int suspendsigno, int
r
Thanks.
On Thursday, 23 May 2013 at 15:22:06 UTC, Gary Willoughby wrote:
I'm just looking at the signals example here:
http://dlang.org/phobos/std_signals.html#.Signal where it says
"Different signals can be added to a class by naming the
mixins.". Has anyone got an example of this plea
I'm just looking at the signals example here:
http://dlang.org/phobos/std_signals.html#.Signal where it says
"Different signals can be added to a class by naming the
mixins.". Has anyone got an example of this please? I'd like to
have a class raise different signals if possible.
24.04.2013 12:47, deadalnix пишет:
On Wednesday, 24 April 2013 at 08:27:15 UTC, Denis Shelomovskij wrote:
19.04.2013 11:45, deadalnix пишет:
On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote:
Another try to describe the problem:
When I get a delegate, I'd like to use it unles
On Wednesday, 24 April 2013 at 08:27:15 UTC, Denis Shelomovskij
wrote:
19.04.2013 11:45, deadalnix пишет:
On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij
wrote:
Another try to describe the problem:
When I get a delegate, I'd like to use it unless it become
invalid.
How does usi
19.04.2013 11:45, deadalnix пишет:
On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote:
Another try to describe the problem:
When I get a delegate, I'd like to use it unless it become invalid.
How does using an object solve that ?
Unless this is a struct-member delegate (whic
On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij
wrote:
Another try to describe the problem:
When I get a delegate, I'd like to use it unless it become
invalid.
How does using an object solve that ?
18.04.2013 18:21, deadalnix пишет:
On Thursday, 18 April 2013 at 13:25:32 UTC, Denis Shelomovskij wrote:
- What is the fundamental problem.
When a delegate is created information about it's outer scope is lost
instead of being stored in it's ptr.
That doesn't mean anything. No information
On Thursday, 18 April 2013 at 13:25:32 UTC, Denis Shelomovskij
wrote:
- What is the fundamental problem.
When a delegate is created information about it's outer scope
is lost instead of being stored in it's ptr.
That doesn't mean anything. No information is stored into a ptr
except an ad
17.04.2013 19:47, deadalnix пишет:
On Wednesday, 17 April 2013 at 10:35:08 UTC, Denis Shelomovskij wrote:
Can you explain what is the problem ?
Code in Issue 9603 doesn't work.
That is not explaining what is the problem. This should contains at least :
- Why it doesn't work.
No ability
17.04.2013 15:26, Timon Gehr пишет:
On 04/17/2013 12:35 PM, Denis Shelomovskij wrote:
...
It will make code in Issue 9603 work.
You have to argue why this is the correct way to fix it. Why would
lifetime control necessarily be linked to implicit object field overhead?
0. I do like this app
On Wednesday, 17 April 2013 at 10:35:08 UTC, Denis Shelomovskij
wrote:
Can you explain what is the problem ?
Code in Issue 9603 doesn't work.
That is not explaining what is the problem. This should contains
at least :
- Why it doesn't work.
- What is the fundamental problem.
- Why this
On 04/17/2013 12:35 PM, Denis Shelomovskij wrote:
...
It will make code in Issue 9603 work.
You have to argue why this is the correct way to fix it. Why would
lifetime control necessarily be linked to implicit object field overhead?
17.04.2013 10:43, deadalnix пишет:
On Wednesday, 17 April 2013 at 06:15:43 UTC, Denis Shelomovskij wrote:
Current behaviour when delegates stays alive when its outer scope is
destroyed is just a bad language design.
No, destroying is unsafe by definition, and this is why GC solve a lot
of pro
On Wednesday, 17 April 2013 at 06:15:43 UTC, Denis Shelomovskij
wrote:
Current behaviour when delegates stays alive when its outer
scope is destroyed is just a bad language design.
No, destroying is unsafe by definition, and this is why GC solve
a lot of problems.
Can you explain what is t
16.04.2013 13:17, deadalnix пишет:
On Tuesday, 16 April 2013 at 07:55:51 UTC, Denis Shelomovskij wrote:
Sorry, I really don't understand what you don't understand.
Let's consider example from Issue 9603 Comment 2 [1]. Do you think
such code must not work?
Also you can look through Issue 9601 d
(Allowong
both strong & weak references as suggested by Kapps seems to be
a good
solution)
std.signals2 supports both, just use strongConnect().
Best regards,
Robert
Am Sun, 14 Apr 2013 21:29:07 +0200
schrieb Robert :
>
> > IMHO if a object still is connected to a active signal it should
> > not be collected. So the place where the signal stores the handler
> > should be scanned by the GC as usual. Then just document clearly
> > that you have to remove a hand
On Tuesday, 16 April 2013 at 07:55:51 UTC, Denis Shelomovskij
wrote:
Sorry, I really don't understand what you don't understand.
Let's consider example from Issue 9603 Comment 2 [1]. Do you
think such code must not work?
Also you can look through Issue 9601 discussion.
[1] http://d.puremagic
16.04.2013 10:10, deadalnix пишет:
On Tuesday, 16 April 2013 at 05:39:32 UTC, Denis Shelomovskij wrote:
Do you mean that tracking an object with a delegate whenever it goes
to just know where it's outer scope is destroyed is not a problem?
Delegate context is allocated on the heap, unless comp
On Tuesday, 16 April 2013 at 05:39:32 UTC, Denis Shelomovskij
wrote:
Do you mean that tracking an object with a delegate whenever it
goes to just know where it's outer scope is destroyed is not a
problem?
Delegate context is allocated on the heap, unless compiler can
prove it can do it on sta
15.04.2013 20:15, deadalnix пишет:
On Monday, 15 April 2013 at 12:07:19 UTC, Denis Shelomovskij wrote:
15.04.2013 13:07, Robert пишет:
2. Make regular D objects on closures [4] to be able to know when
delegate's outer scope is destroyed (this will auto-fix both [5] and
[2], see Comment 2 of [2]
On Monday, 15 April 2013 at 12:07:19 UTC, Denis Shelomovskij
wrote:
15.04.2013 13:07, Robert пишет:
2. Make regular D objects on closures [4] to be able to know
when
delegate's outer scope is destroyed (this will auto-fix both
[5] and
[2], see Comment 2 of [2] for code example)
I still don't
15.04.2013 13:07, Robert пишет:
2. Make regular D objects on closures [4] to be able to know when
delegate's outer scope is destroyed (this will auto-fix both [5] and
[2], see Comment 2 of [2] for code example)
I still don't understand what that buys us. Having a closure being an
object would m
> 2. Make regular D objects on closures [4] to be able to know when
> delegate's outer scope is destroyed (this will auto-fix both [5] and
> [2], see Comment 2 of [2] for code example)
I still don't understand what that buys us. Having a closure being an
object would make it possible to use a we
> Yes, this is how array of weak references will work because this is how
> weak references work. And this shows one mustn't implement general
> facilities in every case they are needed as he will do mistakes and will
> complicate thinks for himself.
>
If an array of weak references works this
> My memories tell me that I was never able to make a _thread safe_ weak
> reference, though. I don't remember exactly, but I think that it was
> because the dispose event happens after all threads have already
> restarted. This means that some thread could extract a strong reference
> from the wea
Am 14.04.2013 19:07, schrieb Robert:
>> Does it mean you disagree with proposed compiler changes and with the
>> idea we have to create weak reference functionality instead of
>> recreating it every time it is needed (beside of theoretical danger such
>> approach already showed it as a bad thing
14.04.2013 21:07, Robert пишет:
Does it mean you disagree with proposed compiler changes and with the
idea we have to create weak reference functionality instead of
recreating it every time it is needed (beside of theoretical danger such
approach already showed it as a bad thing with `std.stdio.F
15.04.2013 7:46, deadalnix пишет:
On Sunday, 14 April 2013 at 07:06:12 UTC, Denis Shelomovskij wrote:
For "working signals" I suppose will be enough fixing of both Issue
9606 [1] and Issue 9603 [2].
IMO, for the first issue we need weak references [3].
IMO, for the second issue we ne
On Sunday, 14 April 2013 at 07:06:12 UTC, Denis Shelomovskij
wrote:
For "working signals" I suppose will be enough fixing of both
Issue 9606 [1] and Issue 9603 [2].
IMO, for the first issue we need weak references [3].
IMO, for the second issue we need to make regular D objects on
c
On Sunday, 14 April 2013 at 17:35:00 UTC, Johannes Pfau wrote:
IMHO if a object still is connected to a active signal it
should not be
collected. So the place where the signal stores the handler
should be
scanned by the GC as usual. Then just document clearly that you
have to
remove a handler t
> IMHO if a object still is connected to a active signal it should not be
> collected. So the place where the signal stores the handler should be
> scanned by the GC as usual. Then just document clearly that you have to
> remove a handler to make sure that garbage collection can really kick
> in.
Am Sun, 14 Apr 2013 19:07:58 +0200
schrieb Robert :
> > Does it mean you disagree with proposed compiler changes and with
> > the idea we have to create weak reference functionality instead of
> > recreating it every time it is needed (beside of theoretical danger
> > such approach already showed
> Does it mean you disagree with proposed compiler changes and with the
> idea we have to create weak reference functionality instead of
> recreating it every time it is needed (beside of theoretical danger such
> approach already showed it as a bad thing with `std.stdio.File` as I wrote)?
>
14.04.2013 15:22, Robert пишет:
There is: http://wiki.dlang.org/Review_Queue
It is currently blocked by:
http://d.puremagic.com/issues/show_bug.cgi?id=8441
There is already a pull request for 8441, but it was not merged yet.
As soon as 8441 gets fixed, I am going to finish up the implementatio
.
For an overview of fixes and improvements over the current
implementation, simply search the forums for std.signals2.
Best regards,
Robert
On Sun, 2013-04-14 at 11:06 +0400, Denis Shelomovskij wrote:
> For "working signals" I suppose will be enough fixing of both Issue 9606
> [1] a
For "working signals" I suppose will be enough fixing of both Issue 9606
[1] and Issue 9603 [2].
IMO, for the first issue we need weak references [3].
IMO, for the second issue we need to make regular D objects on closures
[4] and fix Issue 9602 [5].
Any thoughts about my propos
On May 8, 2012, at 11:13 AM, Shadow_exe wrote:
> Thank You! As would there sometimes You have helped.
> But I'm afraid that these methods me not suitable because libevent already
> creates a queue and turn me not to come out to do.
> Information how to send that is the signal to the next thread I
Thank You! As would there sometimes You have helped.
But I'm afraid that these methods me not suitable because
libevent already creates a queue and turn me not to come out to
do.
Information how to send that is the signal to the next thread I
have not found this information that have been grant
On 05/08/2012 09:00 AM, sclytrack wrote:
On 05/08/2012 04:29 PM, Gor Gyolchanyan wrote:
Try looking at std.concurrency.
You'll find a message passing mechanism there.
On Tue, May 8, 2012 at 2:25 PM, Shadow_exe wrote:
Hello everyone.
Faced with an interesting challenge, and how to solve it and
On 05/08/2012 04:29 PM, Gor Gyolchanyan wrote:
Try looking at std.concurrency.
You'll find a message passing mechanism there.
On Tue, May 8, 2012 at 2:25 PM, Shadow_exe wrote:
Hello everyone.
Faced with an interesting challenge, and how to solve it and found no
tracks.
The problem is the follo
On May 8, 2012, at 3:25 AM, "Shadow_exe" wrote:
> Hello everyone.
> Faced with an interesting challenge, and how to solve it and found no tracks.
> The problem is the following:
> I have 2 thread, which are created in the main flow, respectively, of each
> other, they do not know, but I want to
Yes, there is some communication between the thread, but it is
locked and the thread waits for him not come something like a
signal.
My task is not to block the trade and send a signal in this
thread.
On Tuesday, 8 May 2012 at 14:29:37 UTC, Gor Gyolchanyan wrote:
Try looking at std.concurrenc
Try looking at std.concurrency.
You'll find a message passing mechanism there.
On Tue, May 8, 2012 at 2:25 PM, Shadow_exe wrote:
> Hello everyone.
> Faced with an interesting challenge, and how to solve it and found no
> tracks.
> The problem is the following:
> I have 2 thread, which are created
Hello everyone.
Faced with an interesting challenge, and how to solve it and
found no tracks.
The problem is the following:
I have 2 thread, which are created in the main flow,
respectively, of each other, they do not know, but I want to
create a dialogue between the thread. I want to first th
On Apr 30, 2012, at 8:42 AM, "H. S. Teoh" wrote:
> On Mon, Apr 30, 2012 at 06:50:50AM -0700, Sean Kelly wrote:
>> On Apr 29, 2012, at 9:28 PM, H. S. Teoh wrote:
>>
>>> On Sun, Apr 29, 2012 at 11:47:24PM +0200, deadalnix wrote:
>>> [...]
You misunderstood me (the sentence was not clear). I m
On Mon, Apr 30, 2012 at 06:50:50AM -0700, Sean Kelly wrote:
> On Apr 29, 2012, at 9:28 PM, H. S. Teoh wrote:
>
> > On Sun, Apr 29, 2012 at 11:47:24PM +0200, deadalnix wrote:
> > [...]
> >> You misunderstood me (the sentence was not clear). I mean, you
> >> cannot catch kill and the trick mentioned
On Apr 29, 2012, at 9:28 PM, H. S. Teoh wrote:
> On Sun, Apr 29, 2012 at 11:47:24PM +0200, deadalnix wrote:
> [...]
>> You misunderstood me (the sentence was not clear). I mean, you cannot
>> catch kill and the trick mentioned int he link is linux specific.
>> Obviously, the fact that you cannot c
On Sun, Apr 29, 2012 at 11:47:24PM +0200, deadalnix wrote:
[...]
> You misunderstood me (the sentence was not clear). I mean, you cannot
> catch kill and the trick mentioned int he link is linux specific.
> Obviously, the fact that you cannot catch kill isn't linux specific ;)
Ah, I see.
But real
Le 29/04/2012 00:23, H. S. Teoh a écrit :
On Sun, Apr 29, 2012 at 12:16:15AM +0200, deadalnix wrote:
Le 28/04/2012 22:04, Andrea Fontana a écrit :
How can i catch kill signal to gracefully shutdown my app?
This can be used for other signals :
http://www.deadalnix.me/2012/03/24/get-an
Of course I mean sigterm.
I mixed sigterm and kill (not -9) utility and i wrote sigkill :)
On Saturday, 28 April 2012 at 22:22:00 UTC, H. S. Teoh wrote:
On Sun, Apr 29, 2012 at 12:16:15AM +0200, deadalnix wrote:
But still, you can't catch kill and it is linux specific.
AFAIK, SIGKILL cannot b
On Sun, Apr 29, 2012 at 12:16:15AM +0200, deadalnix wrote:
> Le 28/04/2012 22:04, Andrea Fontana a écrit :
> >How can i catch kill signal to gracefully shutdown my app?
> >
>
> This can be used for other signals :
> http://www.deadalnix.me/2012/03/24/get-an-exception-from
Le 28/04/2012 22:04, Andrea Fontana a écrit :
How can i catch kill signal to gracefully shutdown my app?
This can be used for other signals :
http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-segfault-on-linux-x86-and-x86_64-using-some-black-magic/
But still, you can't catch
On Sat, Apr 28, 2012 at 02:08:06PM -0700, Sean Kelly wrote:
> On Apr 28, 2012, at 1:04 PM, "Andrea Fontana"
> wrote:
>
> > How can i catch kill signal to gracefully shutdown my app?
>
> Gracefully? That's tough. I'd set a flag, then exit the signal
> handler. All threads should periodically che
On Apr 28, 2012, at 1:04 PM, "Andrea Fontana" wrote:
> How can i catch kill signal to gracefully shutdown my app?
Gracefully? That's tough. I'd set a flag, then exit the signal handler. All
threads should periodically check the flag and throw an Error if they see it.
Or an Exception you're su
How can i catch kill signal to gracefully shutdown my app?
66 matches
Mail list logo
