Permalink
Reply
Thanks Steve.
On Wednesday, 17 November 2021 at 17:19:31 UTC, Steven Schveighoffer wrote:
>I have to say, the second I see "How to X with DLL" in this forum, I mark as read and continue. D has a horrible story on DLLs, and it's been like that for as long as I can remember. If there is some infrastructure project that needs attention, it's DLLs. You are right that betterC and importC are useless if using D from C is nigh impossible or so difficult even the experts can't tell you the answer.
HOWEVER -- there is no excuse for the runtime hanging when a possible error is detected from a system call. Your linked discussion was not resolved how it should have been. Either the runtime should deal with that result properly, or it should crash the application completely. Not properly handling system call errors deep in the runtime is not acceptable.
If no bug has been filed on this, please do.
After the experience we've ended up with a workaround that passes requests from C# threads to single thread managed by D's runtime. It works kind off. It's not pretty or most effective, but at least it doesn't crash. Only on DLL unload it has problems sometimes but that is only on program exit anyway so not a big deal for us.
But if I'd do something differently now, I'd end up using betterC only library for this case and avoided runtime completely.
>I believe the GC can be tuned to reduce this, as long as you haven't at one point needed that much memory at once.
Yes, we have found some settings that makes it better (highest impact has progressive growing of the allocated pages set to 1).
>However, it is worth noting that GC (in any language) generally does require more memory than manual allocation or reference counting. D does not have the ability to use a moving GC, because of the type system, which makes compacting GC impossible unfortunately.
Yes it's expected but when I've seen the reported numbers of what is allocated and how much of that is actually free I had my doubts that it is caused only by fragemtation.
But there are no official tools, nor druntime facility to make some GC memory map of what is actually there and where so it's pretty hard to tell and diagnose this.
I've ended up using linux debuging tools to at least see when it allocates next page from what stack, but too many allocations rendered it impossible to process (but at least lead us to the dpq2 allocation problem). After that it became much better so we've decided to move it back to backlog as it would require much more time to move further).
Oof, the dpq2 library should fix that (probably malloc/free the temporary C string). Have you filed a bug on that?
Nope, just internal patch, but I've fixed that: https://github.com/denizzzka/dpq2/issues/161
>If I can separate the use cases here, using D as a main application, on a normal modern server/desktop, I have found using the GC to be a non-issue.
There are problems clearly with:
- using D with GC as a plugin
- using GC in a memory/resource constrained environment
Does that sound fair?
Yes, there are uses where GC is not much of a problem and when is, it can be worked around where it makes sense.
>This doesn't make sense, as I believe async/await in languages enables the compiler to rewrite your functions into a state machine. How it stores the state might not need GC usage, because the compiler is in control of the state creation and the state usage.
I wouldn't expect it to need more GC abilities than scope(exit) does.
I might be wrong, but I guess there would be more to it as a scheduler that would control where the work is actually done controlling some Future/Promise facilities. And when it comes to Thread/Fiber synchronization, then..
But I'm not an expert in this field and as you, I'm more used to seemingly blocking API that is possible in vibe-d/mecca.
>If you refer to UFCS and/or templates, I'm not sure how solvable a problem this is.
No this is more about that it just stops working completely and needs the restart. I can understand that not all code completion is possible, but in this case what has worked just stops working. Not sure why or where (might be a project organization with many subprojects in a relative paths, etc.). But as I said, I'm used to it. This is more about newcomers that might be scared away ;-) For debugging I use printf/gdb and I can live with that.
>Having the other options is a nice possibility, but I would be very much against removing the GC, or refactoring everything so I have to think about non-GC options.
We're on the same page here. I'd also like the best of both worlds ;-)
Removing betterC or forcing GC on user would be a show stopper for me too.
Such is life. If you want an ecosystem built around a certain paradigm or low level design choice, you have to either create it or get others to join you in that paradigm.
D does give you the opportunity to do that, it certainly does take a lot of critical mass to do that.
Yes, unfortunately I haven't found any other language that I would like more. So even with its quirks, D is great but definitely deserves to be better.
