Mirror of forum.nim-lang.org

5921 :: Does --gc:arc remove dependency on NimRtl.dll?

• akavel (orginal) [2020-02-11T20:02:36+01:00] view original

  If I write a DLL with --gc:arc, does it no longer require NimRtl.dll?

---

• Araq (orginal) [2020-02-11T20:41:30+01:00] view original

  If you use nim --gc:arc -d:useMalloc it's all delegated to your malloc implementation which might be ready for DLLs, it depends on your libc implementation.

  In general, nimrtl.dll is not required when you write a DLL, it is however a good idea to use nimrtl.dll if you want to produce more than one DLL.

  The real issue with DLLs is the heap and how to share it. If DLL A calls alloc, can DLL B call dealloc with the same pointer? If both DLLs use nimrtl.dll then the answer is yes.

---

• akavel (orginal) [2020-02-11T22:56:03+01:00] view original

  Hm; so, assuming that the master app always calls "destructors" correctly from the DLL that created the objects, I might already not need nimrtl.dll even with the regular (non-arc) gc? (I definitely want more than one DLL - I'm generally interested in writing plugins for some "master app".) Or do I misunderstand?

---

• rayman22201 (orginal) [2020-02-12T00:28:17+01:00] view original

  Maybe of interest to you, but FEUD did exactly this. It implements a successful plugin system using DLLS. https://github.com/genotrance/feud/

  It's not super actively developed anymore, but the code might provide some good inspiration. Also the author is active here and on irc (he goes by @shashlick on irc). He might have some good tips.

---

• akavel (orginal) [2020-02-12T01:26:46+01:00] view original

  Hm, FEUD seems a big project, so at first glance, looks like it may be tough to crunch...? also, if the main app is already in Nim, I'd assume nimrtl.dll probably isn't much of an issue in this case? But I'll try to keep in mind to ask @shashlick if I have time to drop by IRC at some point in future. Thanks for the heads up!

---

• shashlick (orginal) [2020-02-12T05:00:31+01:00] view original

  All the code lives in src/plugin.nim. Plugins use src/pluginapi.nim and the plugin folder has many examples. Some stuff is in src/globals.nim that will need to get pulled out. src/sci.nim shows how to start the plugin system. It should be easy to extract and use it for some simple tests.

  Feud is Windows only today but I have tested the plugin system on Linux and it works fine, should be cross platform.

  Also, it is only functional and tested on --gc:boehm since it manages memory correctly across threads and DLLs. --gc:arc will do the same, per Araq, but it has not been tested.

  If there is real interest, I am willing to pull out the plugin system from feud and make it an independent package that can be installed with nimble.

---

• akavel (orginal) [2020-02-12T10:48:27+01:00] view original

  Thanks for the leads!

  In my personal case, as of now I'm interested specifically in writing DLL/.so modules for Lua and LuaJIT, on Windows & Linux & Mac. Might also potentially be interested in writing DLL plugins for some other Windows apps (like Notepad++). If any support in this area could be installed via Nimble, I'm absolutely interested, though I guess what you're talking about is probably more about the "master app" part?

---