• Peter Sommerfeld (20/20) Oct 23 2012 Hi!
• Sean Kelly (9/33) Oct 25 2012 In D, the main thread will join all non-daemon threads before calling =
• =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (6/33) Oct 25 2012 What's used on OS X? I forget...
• Sean Kelly (5/7) Oct 25 2012 The method used is similar to how GC works on Windows--there's a kernel ...
• Jacob Carlborg (4/8) Oct 25 2012 The Posix functions weren't working properly?
• Sean Kelly (13/21) Oct 30 2012 kernel call that can be used to explicitly suspend a thread. I can't =
• =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (6/17) Oct 30 2012 Real time signals as in?
• Sean Kelly (11/20) Oct 30 2012 druntime used the signal approach on OSX and had deadlock issues in the ...
• Peter Sommerfeld (5/12) Oct 25 2012 [snip]

"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

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.=

=?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

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.=

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

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> =


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

=20
 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.
=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.=

=?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

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, =


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.
=20
 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.
=20

=20
 Real time signals as in?

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

"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.

[snip]
 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