non-blocking c# plugin

Hi all,

Im trying to hack my way through a c# plugin (compiled, not a c# script).

That I'd like to do is to do some processing without blocking grasshopper and when done, update the output variable.

If I put that function on a new thread I couldnt find a way to update the component later correctly.

What is the bast and probably simple way to run just one function that updates a variable (or it can return one, but I thought that a global one is a bit better) in the background without blocking?

Thanks

private static String results = String.Empty;

private static Boolean tDone = false;

protected override void SolveInstance(IGH_DataAccess DA)

{

Listspan class="s3">Line> lines = new Listspan class="s3">Line>();

if (!DA.GetDataList(0, lines)) { return; }

// can take a lot of time to finish!!

// this updates the global "results" string

DoSomeHardWork(lines);

DA.SetDataList(0, results);

string bb = Convert.ToString(tDone);

DA.SetData(1, bb);

}

Replies to This Discussion

Permalink Reply by Andrew Heumann on July 2, 2014 at 9:35am

I think you'll need to set up a delegate function tied to an event - and that delegate can call ExpireSolution. See David's response here:

http://www.grasshopper3d.com/forum/topics/threads-expiresolution-pr...

Permalink Reply by Andrew Heumann on July 2, 2014 at 9:38am

Actually david's script does something slightly different from what I describe - but it may work for you.

Permalink Reply by Tasos Varoudis on July 2, 2014 at 12:26pm

Thanks Ill check it.

My knowledge of C# ideas and concept is zero but Ill try to google it.

Im coming from a C++ background that is why Im trying to hack my way through the problem :)

Permalink Reply by Tasos Varoudis on July 10, 2014 at 5:12am

I dint get this working.

Anyone has code snippets that can share?

Thanks!

Permalink Reply by Vicente Soler on July 10, 2014 at 4:31pm

David's script that Andrew linked to works for me. I think there was an infinite loop in the RunScript code. I modified it a bit so that it calculates something in the background that would take a while (3d voronoi cells from a list of points) and outputs the result when it's finished. It's "non blocking", while it's calculating the canvas is responsive and so on.

Attachments:

Nonblockingvoronoi.gh, 10 KB

Permalink Reply by Vicente Soler on July 11, 2014 at 5:23am

You can even make it non-blocking and multithreaded at the same time using a simple parallel.foreach loop. I limited the number of logical processors to be used to half of the available.

In this case the voronoi cells are probably in a different order as the points, it should be easy to keep the order by doing the slicing in a parallel.foreach and using a normal foreach for adding them to the brep list.

In the previous file I forgot to remove the point that corresponds to the cell for slicing.

Attachments:

Nonblockingvoronoi_mulithreaded01.gh, 6 KB

Permalink Reply by Tasos Varoudis on July 11, 2014 at 6:02am

thanks Ill check.

parallel.for is not working for me.

I have a remote call that takes time and the results are coming via TCP.

Thanks

Permalink Reply by Tasos Varoudis on July 15, 2014 at 9:55am

//Invoke the component on the main UI thread.

Action dlg = ExpireComponent;

Rhino.RhinoApp.MainApplicationWindow.Invoke(dlg);

return;

Any idea how to change this in order to work in a compiled C# plugin?

Rhino.RhinoApp gives a error:

Error 1 The type 'System.Windows.Forms.IWin32Window' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

Permalink Reply by David Rutten on July 15, 2014 at 10:23am

Did you add a reference to System.Windows.Forms?

David Rutten

david@mcneel.com

Permalink Reply by Tasos Varoudis on July 16, 2014 at 2:54am

true! :)

Thanks

Permalink Reply by Tasos Varoudis on July 16, 2014 at 3:47am

I got it working eventually with a couple of hiccups.

Runs the first time ok, but then if you change/update the input the plugin wont update (re-run)... at some point after a minute or so, it will run again :)

is calling "thread = null" nice in C# without properly killing the thread?

Permalink Reply by Arend on July 16, 2014 at 10:55am

Since you said you're using C++ components, I suspect that setting thread = null, can be the highway to memory-leak paradise.

http://stackoverflow.com/questions/1051838/killing-a-thread-c

So: be nice, wait for a nice thread-office to flag you down, and please clean up after your thread. If your C++ component does not implement a way to stop it's buisness, you may have to wait for it to gracefully end it's task.