MultiThreading "offSetCurveOnSurface" in python problem

Hi there,

I’m revisiting an attempt to get this function to multi thread, since we have several hundred curves and only one surface.
Could somebody give me a hint why this code doesn’t work? (neither multi thread or standard)

Thanks

import ghpythonlib.components as ghcomp
import ghpythonlib.parallel

#custom function that is executed by parallel.run
def offset_on_surface(curves):
result= ghcomp.OffsetonSrf(curves, surface, distance)
if result: return result.curves

if parallel:
offsetcurves = ghpythonlib.parallel.run(offset_on_surface, curves, True)
else:
offsetcurves = ghcomp.OffsetonSrf(curves, surface, distance)

what does OffsetonSrf return?

I tested the example code and it works.

how is your Grasshopper file setup?


import ghpythonlib.components as ghcomp
import ghpythonlib.parallel

#custom function that is executed by parallel.run
def slice_at_angle(plane):
    result = ghcomp.BrepXPlane(brep, plane)
    if result: return result.curves

if parallel:
    slices = ghpythonlib.parallel.run(slice_at_angle, planes, True)
else:
    slices = ghcomp.BrepXPlane(brep, planes).curves


Hi Thorsten,

If particular ghcomp function has only one output (like OffsetonSrf does), then output is not named. Meaning you only need:

return result

And you mixed the order of input parameters. It should be:

ghcomp.OffsetonSrf(curves, distance, surface)

Hi eivl

thanks for responding.

So far I din’t had any return/ouput/error message with this, that’s why I asked here.
And it was exactly that “slice” example I used as basis for my offset.

I just tried djordje’s tip with the return and input order, now it works.

Thanks djordje,

the two hints of you solved my problem!

By the way, wouldn’t it be helpful to have a library of all “obvious” functions which really could benefit of multi-threading somewhere?
If everybody “translates” one of them, we could have all of them done in a week!?

Best
Thorsten

well, I tried it with the very basic test scenario (only 2 curves and one surface)
now. when using 380 curves, it crashes with every try.

crash dump message says:
“the thread tried to read from or write to a virtual address or which it does not have the appropriate access”

The taskmanager didn’t show more than 500 mb of RAM used at the time of crash.

That seems not to be a problem with my rhino file, doesn’t it?

Keep in mind that Rhino is not thread safe. You can create worker thread. But they cannot do anything with Rhino or the Rhino document. Treads can manipulate geometry as long as it is your own copy (and not in the document). Also, don’t share objects between threads…

Even then, my experience is that spurious crashes can still occur if you’re not careful. I ended up parallelising a certain algorithm we use a lot in C++ after the C# implementation gave weird intermittent crashes.

I also had often crashes with ghpythonlib.parallel. Have just tried replicating the code from this topic, and experienced the same crash when parallel is used.

Thanks Dael, Menno and djordje,

that’s good to know but sad to hear.

Even when other languages might seem more stable for paralleling tasks, I will not really change to C++ or C# I think…
Best
Thorsten