Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
October 23, 2012 Threading Question | ||||
---|---|---|---|---|
| ||||
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 Re: Threading Question | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Sommerfeld | 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 Re: Threading Question | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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 Re: Threading Question | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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 Re: Threading Question | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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 Re: Threading Question | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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 Re: Threading Question | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 Re: Threading Question | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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 Re: Threading Question | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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.
|
Copyright © 1999-2021 by the D Language Foundation