www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Threading Question

reply "Peter Sommerfeld" <noreply rubrica.at> writes:
Hi!

I'm new to D an not a native speaker so I may misunderstand
the following sentence of the thread documentation.

"final  property void isDaemon(bool val);

Sets the daemon status for this thread. While the runtime
will wait for all normal threads to complete before tearing
down the process, daemon threads are effectively ignored and
thus will not prevent the process from terminating. In effect,
daemon threads will be terminated automatically by the OS when
the process exits."

That sounds to me as if the daemon will be finished when the
main-thread has finished. But in my understanding daemons will
survive the termination of the main-thread and be killed by
a signal (KILL, SIGTERM etc) or finish itself.

I think that is the case here too. Is that true ?

Another question: I cannot find a reference how D deals with
OS SIGNALS, especially about differences between the platform
(*nix; Windows, Mac). Can you explain or point me to the
documentation?

Peter
Oct 23 2012
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Oct 23, 2012, at 11:25 AM, Peter Sommerfeld <noreply rubrica.at> =
wrote:


 Hi!
=20
 I'm new to D an not a native speaker so I may misunderstand
 the following sentence of the thread documentation.
=20
 "final  property void isDaemon(bool val);
=20
 Sets the daemon status for this thread. While the runtime
 will wait for all normal threads to complete before tearing
 down the process, daemon threads are effectively ignored and
 thus will not prevent the process from terminating. In effect,
 daemon threads will be terminated automatically by the OS when
 the process exits."
=20
 That sounds to me as if the daemon will be finished when the
 main-thread has finished. But in my understanding daemons will
 survive the termination of the main-thread and be killed by
 a signal (KILL, SIGTERM etc) or finish itself.
=20
 I think that is the case here too. Is that true ?



In D, the main thread will join all non-daemon threads before calling =
static dtors or performing any other cleanup.  Daemon threads will =
continue to run until the process exits.  So daemon threads are =
basically just C-style kernel threads.



 Another question: I cannot find a reference how D deals with
 OS SIGNALS, especially about differences between the platform
 (*nix; Windows, Mac). Can you explain or point me to the
 documentation?



The GC in D uses SIGUSR1 and SIGUSR2 to coordinate collections on Posix =
OSes (except for OSX).  You're free to use any other signal just as you =
would in C.=
Oct 25 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 26-10-2012 01:11, Sean Kelly wrote:

 On Oct 23, 2012, at 11:25 AM, Peter Sommerfeld <noreply rubrica.at> wrote:


 Hi!

 I'm new to D an not a native speaker so I may misunderstand
 the following sentence of the thread documentation.

 "final  property void isDaemon(bool val);

 Sets the daemon status for this thread. While the runtime
 will wait for all normal threads to complete before tearing
 down the process, daemon threads are effectively ignored and
 thus will not prevent the process from terminating. In effect,
 daemon threads will be terminated automatically by the OS when
 the process exits."

 That sounds to me as if the daemon will be finished when the
 main-thread has finished. But in my understanding daemons will
 survive the termination of the main-thread and be killed by
 a signal (KILL, SIGTERM etc) or finish itself.

 I think that is the case here too. Is that true ?



 In D, the main thread will join all non-daemon threads before calling static
dtors or performing any other cleanup.  Daemon threads will continue to run
until the process exits.  So daemon threads are basically just C-style kernel
threads.



 Another question: I cannot find a reference how D deals with
 OS SIGNALS, especially about differences between the platform
 (*nix; Windows, Mac). Can you explain or point me to the
 documentation?



 The GC in D uses SIGUSR1 and SIGUSR2 to coordinate collections on Posix OSes
(except for OSX).  You're free to use any other signal just as you would in C.



What's used on OS X? I forget...

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 25 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-26 01:18, Sean Kelly wrote:

 On Oct 25, 2012, at 4:12 PM, Alex Rønne Petersen <alex lycus.org> wrote:

 What's used on OS X? I forget...



 The method used is similar to how GC works on Windows--there's a kernel call
that can be used to explicitly suspend a thread.  I can't remember the function
name offhand though.



The Posix functions weren't working properly?

-- 
/Jacob Carlborg
Oct 25 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 30-10-2012 19:04, Sean Kelly wrote:

 On Oct 25, 2012, at 11:18 PM, Jacob Carlborg <doob me.com> wrote:


 On 2012-10-26 01:18, Sean Kelly wrote:

 On Oct 25, 2012, at 4:12 PM, Alex Rønne Petersen <alex lycus.org> wrote:

 What's used on OS X? I forget...



 The method used is similar to how GC works on Windows--there's a kernel call
that can be used to explicitly suspend a thread.  I can't remember the function
name offhand though.



 The Posix functions weren't working properly?



 The semaphore implementation for OSX is not signal-safe.  Originally, druntime
used the signal approach on OSX and had deadlock issues in the signal handler
(OSX semaphores wrap a global mutex to obtain something from a shared pool). 
Also, semaphores on OSX are just ridiculously slow.  The current method for
suspending and scanning threads on OSX is much faster.  I wish Posix in general
had the same feature.  Using signals is really a hack.

 It may be worth dropping use of SIGUSR1/2 in favor of the realtime signals as
well, since SIGUSR1/2 are in pretty common use.



Real time signals as in?

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 30 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Oct 25, 2012, at 4:12 PM, Alex R=F8nne Petersen <alex lycus.org> =
wrote:

=20
 What's used on OS X? I forget...



The method used is similar to how GC works on Windows--there's a kernel =
call that can be used to explicitly suspend a thread.  I can't remember =
the function name offhand though.=
Oct 25 2012
prev sibling next sibling parent "Peter Sommerfeld" <noreply rubrica.at> writes:
Sean Kelly <sean invisibleduck.org> wrote:
[snip]

 In D, the main thread will join all non-daemon threads before calling  
 static dtors or performing any other cleanup.  Daemon threads will  
 continue to run until the process exits.  So daemon threads are  
 basically just C-style kernel threads.




 The GC in D uses SIGUSR1 and SIGUSR2 to coordinate collections on Posix  
 OSes (except for OSX).  You're free to use any other signal just as you  
 would in C.



Thanks for clarification Sean!

Peter
Oct 25 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Oct 25, 2012, at 11:18 PM, Jacob Carlborg <doob me.com> wrote:


 On 2012-10-26 01:18, Sean Kelly wrote:

 On Oct 25, 2012, at 4:12 PM, Alex R=F8nne Petersen <alex lycus.org> =







=20
 What's used on OS X? I forget...



 The method used is similar to how GC works on Windows--there's a =






remember the function name offhand though.

=20
 The Posix functions weren't working properly?



The semaphore implementation for OSX is not signal-safe.  Originally, =
druntime used the signal approach on OSX and had deadlock issues in the =
signal handler (OSX semaphores wrap a global mutex to obtain something =
from a shared pool).  Also, semaphores on OSX are just ridiculously =
slow.  The current method for suspending and scanning threads on OSX is =
much faster.  I wish Posix in general had the same feature.  Using =
signals is really a hack.

It may be worth dropping use of SIGUSR1/2 in favor of the realtime =
signals as well, since SIGUSR1/2 are in pretty common use.=
Oct 30 2012
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Oct 30, 2012, at 11:06 AM, Alex R=F8nne Petersen <alex lycus.org> =
wrote:


 On 30-10-2012 19:04, Sean Kelly wrote:

=20
=20
 The semaphore implementation for OSX is not signal-safe.  Originally, =






signal handler (OSX semaphores wrap a global mutex to obtain something =
from a shared pool).  Also, semaphores on OSX are just ridiculously =
slow.  The current method for suspending and scanning threads on OSX is =
much faster.  I wish Posix in general had the same feature.  Using =
signals is really a hack.

=20
 It may be worth dropping use of SIGUSR1/2 in favor of the realtime =







=20



 Real time signals as in?



SIGRTMIN - SIGRTMAX.  Linux supports them, but I'm not sure which other =
Posix OSes.=
Oct 30 2012