February 20, 2015 Re: GC deadlocks on linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Byron Heads | On Wednesday, 18 February 2015 at 20:27:08 UTC, Byron Heads wrote:
> I have a medium size daemon application that uses several
> threads, libasync, and daemonize. On windows it runs correctly
> with GC enabled, but on linux the GC causes a deadlock while
> allocating memory.
Can you reliably reproduce the deadlock?
If so please attach a gdb to the deadlocked process and provide us back traces of all threads? If you can share the code (maybe privately), that would help as well.
|
February 20, 2015 Re: GC deadlocks on linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Byron Heads | On Wednesday, 18 February 2015 at 20:27:08 UTC, Byron Heads wrote: > Adding core.memory.GC.disable; to main causes the application to > work correctly (and quickly till it runs out of memory :D ) GC.disable shouldn't run OOM, BTW. http://dlang.org/phobos/core_memory.html#.GC.disable |
February 20, 2015 Re: GC deadlocks on linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On Wednesday, 18 February 2015 at 20:41:12 UTC, Dicebot wrote: > Any chance you are using gdm-3.12.x? > > I was so mad when I have encountered this: > https://issues.dlang.org/show_bug.cgi?id=4890 Indeed, maybe http://dlang.org/phobos-prerelease/core_thread.html#.thread_setGCSignals might help. We should probably try to improve druntime to only use a single signal for suspending and resuming. |
February 20, 2015 Re: GC deadlocks on linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to ketmar | On Friday, 20 February 2015 at 12:47:58 UTC, ketmar wrote:
> 3rd party library that already initialized something, or... you got the idea. ;-)
Yeah, either use plain C or avoid 3rd party libraries... I guess that includes phobos ;)
|
February 20, 2015 Re: GC deadlocks on linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Byron Heads | On Wednesday, 18 February 2015 at 20:27:08 UTC, Byron Heads wrote: > System: > DMD 2.066.1 Can you also try the latest beta please, maybe we already fixed something. http://forum.dlang.org/post/54E49E2D.2010800@dawg.eu |
February 20, 2015 Re: GC deadlocks on linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad Attachments: | On Fri, 20 Feb 2015 14:33:29 +0000, Ola Fosheim Grøstad wrote:
> On Friday, 20 February 2015 at 12:47:58 UTC, ketmar wrote:
>> 3rd party library that already initialized something, or... you got the idea. ;-)
>
> Yeah, either use plain C or avoid 3rd party libraries... I guess that includes phobos ;)
maybe even druntime to some extent. and, of course, no other D libraries, as who knows what they can do in their module initialisers...
|
February 20, 2015 Re: GC deadlocks on linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Byron Heads | On 02/18/2015 09:35 PM, Byron Heads wrote: >> > > > I am in the daemonize library > > https://github.com/NCrashed/daemonize Might want to try using libasync without multiple threads. http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them |
February 20, 2015 Re: GC deadlocks on linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On Friday, 20 February 2015 at 15:17:22 UTC, Martin Nowak wrote:
> Might want to try using libasync without multiple threads.
> http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them
Or you temporarily disable the GC before forking and enable it again afterwards.
|
February 20, 2015 Re: GC deadlocks on linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On Friday, 20 February 2015 at 14:33:31 UTC, Ola Fosheim Grøstad wrote:
> Yeah, either use plain C or avoid 3rd party libraries... I guess that includes phobos ;)
AFAIK, in early days of unix there were no threads, processes were single-threaded, fork was the way to concurrency and exec was the most efficient way to run a program in memory-constrained conditions of 70s (kbytes of RAM!). Plain unix-like single-threaded processes, plain C heap, which didn't serialize access, because no threads, and worked fine with just virtual memory, which fork got right. That's the model, which should work the best with fork+exec.
|
February 20, 2015 Re: GC deadlocks on linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On Friday, 20 February 2015 at 22:07:56 UTC, Kagamin wrote:
> AFAIK, in early days of unix there were no threads, processes were single-threaded, fork was the way to concurrency and exec was the most efficient way to run a program in memory-constrained conditions of 70s (kbytes of RAM!). Plain unix-like single-threaded processes, plain C heap, which didn't serialize access, because no threads, and worked fine with just virtual memory, which fork got right. That's the model, which should work the best with fork+exec.
Indeed, actually, not only for the early days, but for the first 20 years or so! :-D
Single thread, C, fork and a pipe + limited use of shared memory is a quite clean model. The underlying principle in Unix is to build complex software from many isolated simple units.
This robust philosophy somehow got lost in the quest for bleeding edge.
|
Copyright © 1999-2021 by the D Language Foundation