Thread overview
Threading Question
Oct 23, 2012
Peter Sommerfeld
Oct 25, 2012
Sean Kelly
Oct 25, 2012
Sean Kelly
Oct 26, 2012
Jacob Carlborg
Oct 30, 2012
Sean Kelly
Oct 30, 2012
Sean Kelly
Oct 25, 2012
Peter Sommerfeld
October 23, 2012
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
October 25, 2012
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.
October 25, 2012
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
October 25, 2012
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.
October 25, 2012
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
October 26, 2012
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
October 30, 2012
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.
October 30, 2012
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
October 30, 2012
On Oct 30, 2012, at 11:06 AM, Alex Rønne Petersen <alex@lycus.org> wrote:

> On 30-10-2012 19:04, Sean Kelly wrote:
>> 
>> 
>> 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?

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