I write a code calculating speed & position vectors as steps parallel & synced.
each 24 calcultion steps the new positions are written with std.json.
This all works fine.

(dmd2 @ Visual Studio 2017 CE 15.5.4, Visual D 0.46.0)

Now when I increase the anmount of steps...
the process lost its... track? - it just does something.
There is no error or debugging message and no hint.

I can write three json, the forth failed.
Now for the best thing of my discovery:
when I switch from x64 to x86 I can write 7 files.

?

so I begin debugging on last successfull writeln()
maybe there are some stupid values in the fourth string.

stepping through with debugger shows that creating a new tag in an object contains the last successfull line (in std.json). the asignment to aa[] in jsonvalue failed. but not just failed: the debugger just dissapears resulting in this infinity 'background loop ?' again.

-> Source not available
The debugger information of this module contain no sourceinformations.

?

I thought maybe the parameter string is buggy so I just removed this last asignment.
But the same happened again. Now I got even more files. I debugg again...
And I found: the jump off point change. Debugging now left my sourcecode while calling a function returning a new jsonvalue. I don't see why, it jumps out on function definition. So I think it must happen while allocating new memory for the jsonvalue.

?

switching back to x64:
As expected, now I got half of the files. (keeping the last json tag removed)
BUT
It again lost track on annother line of code.
without any influence of json. in step 117 (without export).
this time while creating the parallel calculation:
  foreach (ref w; taskPool.parallel(worktupels, 1)){...}
  --> in parallelism.d @line 3686: int opApply(scope NoIndexDg dg)


So...

Please help me ¯\_(ツ)_/¯

changed my design from extending thread to just using taskPool.parallel.
seems like my implementation left to many open threads in background and forcing the operation system to cut them off.

thought start() and join() allowed me to use start() again on the same thread object in next loop.
But there is some leakage... are they not 'self-closig' after finnishing run() ?

works now
but you are welcome to leave a statement.

On Sunday, 11 February 2018 at 17:28:25 UTC, Eld0r wrote:
> changed my design from extending thread to just using taskPool.parallel.
> seems like my implementation left to many open threads in background and forcing the operation system to cut them off.
>
> thought start() and join() allowed me to use start() again on the same thread object in next loop.
> But there is some leakage... are they not 'self-closig' after finnishing run() ?
>
> works now
> but you are welcome to leave a statement.

For a statement... I'm glad you found your way! However nobody can debug a program they can't read so please always post a small working example in order for others to understand your issue and be able to reproduce it ;)