• Eld0r (44/44) Feb 11 2018 I write a code calculating speed & position vectors as steps
• Eld0r (10/10) Feb 11 2018 changed my design from extending thread to just using
• Cym13 (5/15) Feb 11 2018 For a statement... I'm glad you found your way! However nobody

Eld0r <dlang.eld0r gmx.net> writes:

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 ¯\_(ツ)_/¯

Eld0r <dlang.eld0r gmx.net> writes:

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.

Cym13 <cpicard openmailbox.org> writes:

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 ;)