Re: Which Multithreading Solution?
On 3/4/18 11:31, Drew Phil wrote: Hey there! I'm trying to figure out which of D's many multithreading options to use for my application. I'm making a game that runs at 60 frames per second that can also run user-made Lua scripts. I would like to have the Lua scripts run in a separate thread so they can't delay frames if there's a lot of work to do in a burst, but I also need it to be able to update and read from the thread where everything else is. I don't think message passing is going to cut it because the Lua thread is going to need to be able to request to set a value in D on one line, and then request that value back on the next line, and that value needs to be updated at that point, not at the end. I've been marking things as __gshared to get them working, but I think that just makes a copy on all threads, which seems pretty excessive when mostly the Lua will just be reading values, and occasionally calling a function in D to change some values. I think I should try to do some kind of lock thing, but I'm not really sure how that works. If someone could advise me on what tact I should take, that would be very helpful. Thanks! core.thread is probably your best bet in the long-term. std.concurrency could actually be used though, just call receive() immediately after send(). However, the performance of this may not be what you want. My recommendation would be to use std.concurrency to get the logic correct first, then worry about perf. And using std.concurrency will get some of the basic concepts (ex: immutable/shared) right that will port over the regular threads. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: pointer not aligned
On 3/30/17 10:47 PM, H. S. Teoh via Digitalmars-d-learn wrote: On Fri, Mar 31, 2017 at 04:41:10AM +, Joel via Digitalmars-d-learn wrote: Linking... ld: warning: pointer not aligned at address 0x10017A4C9 (_D30TypeInfo_AxS3std4file8DirEntry6__initZ + 16 from .dub/build/application-debug-posix.osx-x86_64-dmd_2072-EFDCDF4D45F944F7A9B1AEA5C32F81ED/spellit.o) ... and this goes on forever! More information, please. What was the code you were trying to compile? What compile flags did you use? Which compiler? T I see this on OSX as well. Any code referencing Phobos appears to produce this. It appear after updating the XCode command line tools. It does not appear to effect program execution, but the pages of warnings are really quite annoying. DMD 2.073.2 -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Are there plans to make mono D work with current version?
On 1/25/17 5:22 PM, Lucas wrote: On Wednesday, 25 January 2017 at 23:00:05 UTC, James Buren wrote: On Wednesday, 25 January 2017 at 22:37:30 UTC, Lucas wrote: [...] Most likely, you are dealing with this issue: https://github.com/aBothe/Mono-D/issues/648 MonoDevelop 5.x is the latest version supported. They haven't gotten around to making it compatible with anything newer due to various reasons, mainly it being that MonoDevelop has completed changed the plugin API again. If you really need Mono-D, you are stuck with MonoDevelop 5.x for now. Too bad. What are the D IDE options currently? I might just downgrade to MonoDevelop 5.x I'd recommend VSCode with Code-D works very well for me. https://github.com/Pure-D/code-d -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: How to detect free/unfree memory segments?
On 12/23/16 8:39 PM, Suliman wrote: On Saturday, 24 December 2016 at 01:15:43 UTC, jkpl wrote: On Friday, 23 December 2016 at 06:18:02 UTC, Suliman wrote: I would like to visualize how GC works and display free/not free memory segments. How I can understand which of them are used and which not? Could anybody explain what dangerous of memory fragmentation in languages without GC? Am I right understand that there is stay some small memory chunks that very hard to reuse? You start with a wrong assumption. The C malloc functions is not just a nasty and mean memory provider. Several implementations uses internally freelists. Which means that the gaps created by a free() may be filled again. For example - TCMallocator use free lists - GCC C malloc use free lists (as stated here http://www.gnu.org/software/libc/manual/html_node/Freeing-after-Malloc.html) - for snn.lib malloc (used by DMD win32) I can't say. So there is no any problems with memory fragmentation and all used memory arr successfuly reuse? Strictly speaking fragmentation is a problem in D regardless of GC/nogc. The *only* way to reduce fragmentation is to use a compaction algorithm of some kind. Again this is separate from GC/nogc, because you could lock a memory pool you made and apply the same compaction algorithm, as opposed to using a GC algo. For example, lets say you have the following unfragmented memory layout: 24 Now delete the "four" memory: 2- And allocate a new "six" object, which just happens to fit inside the the space available on the freelist: 266--- Note the three dashes. Those will go unused until such time as an object small enough to fit inside is allocated. However, what happens if the object is not exactly the space available? 26677- The dashes are what is commonly referred to as fragmentation. In that, small fragments of memory go unused because nothing fits inside them. With a Precise GC you can implement a compacting collector that reorders blocks of memory within the address space to reduce or eliminate fragmentation. -- Adam Wilson IRC: LightBender //quiet.dlang.dev
