nim r --d:release --mm:atomicArc thisexample
And we should make it the default.
And we should make it the default.
ugh no thanks - making the entire codebase thread-synchronized because (in a well-designed application) you have a few transfer points between threads is not gonna end well.
Great news! Why does your getandpost.nim example only use epolldispatcher for the POST requests/server and not the GET req/server?
BTW, thanks for all the helpful info in the release notes for v8.
No reason. Example 2 merely tries to demonstrate the central tenet of GuildenStern, namely that you can run, switch, and customize easily between different kinds of servers in different ports so that there is optimized handling available for any kind of client workflow pattern your application might encounter.
If there is no need for multiple dispatcher logic in same application, you can definitely stick to one. If your platform supports it, I recommend trying out the new epolldispatcher, because it delegates scheduling to kernel and should therefore be a robust choice.
When I run stress tests with atomicArc, I get rock-solid performance without a noticeable degradation in speed. So, yes, I will use atomicArc as my default everywhere, at least until I learn to prevent gc from crashing by using those advanced tools @arnetheduck is referring to.
When I run nim examples/wsmulticasttest with --mm:arc, the program sooner later hits something like this:
/home/allin/.choosenim/toolchains/nim-2.2.0/lib/system.nim(180) handleRead
(sometimes, only with useMalloc:) free(): double free detected in tcache 2
...
/home/allin/.choosenim/toolchains/nim-2.2.0/lib/system/arc.nim(196) nimDestroyAndDispose
(sometimes, without useMalloc:) /home/allin/.choosenim/toolchains/nim-2.2.0/lib/system/arc.nim(229) nimDecRefIsLastIf someone knows a fix for that offending proc, help would be appreciated. In the meantime, atomicArc is my friend.
I recently just dove into threadsanitizer, and it really helped me find some places where ARC + temporary "hidden" copies were crashing my threaded code. Also use debugger:native and it'll use the itanium name mangling and give you a better stacktrace.
I got curious. Looks like you're passing GuildenStern ref object to threads. That'd cause ARC thread issues even if the object isn't freed as there can still be increment and decrements. You could possibly turn "server" into a plain object and put it into a SharedPtr frim threading/smartptrs. If you own the object that's easiest thing to do. Lots of other ways too.
That's if you wanna use regular ARC. Atomic Arc mostly gets expensive only if there's lots of contention. Doesn't look like you'll have that.