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.

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

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.

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 ;)

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

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

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

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.

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.

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.