Due to the Rhino architecture the meshing is done only on one CPU core. So i already tried to instantiate more than one Rhino.Inside process, but this does not work if they are running within a windows service.
So is there another way to do a multiple conversion on the same computer and use more than one Core?
Is it possible to instantiate more RhinoCore classes in different threads within one process (is it thread-safe)?
@nathanletwory thanks for the hint, but that was not was i expected from the answer. You gave me a workaround for one special case. What if i want to do a nurbs boolean?
So my intention was to get more insight in the Rhino.Inside technology do understand what’s possible or not. If i do not understand it, i can not include this technology in my decision process.
At the moment Rhino.Inside is a nice “Beta” to play around, but nothing i would use in productive environment.
Functions in the Rhino.Geometry namespace of RhinoCommon are thread-safe. I’m assuming that is what we are referring to when we are using the term RhinoCore
The RhinoCore class in RhinoCommon is used to get Rhino loaded into another process. Once you’ve loaded the DLL into the process, you can’t load more copies. This is simply how the operating system works. The RhinoCore class is inended to only have a single instance. If you want multiple processes using RhinoCore, you would need to orchestrate communication between these processes which in a way is how hops<->compute works.
Ok i understood so far, that i can use/load Rhino.Inside only once in a process, which makes perfect sense.
About the last part you said @stevebaer i don’t know anything about hops<->compute communication, but as i understood it would be possible to start more processes, each loads his own Rhino.Inside.
As i already mentioned in the first post, i tried this and it works if i’m logged on interactively and start 2 or more processes.
But it does not work if it runs as a windows service. So i assume this is something Rhino.Inside is limiting or it is currently not covered by the license terms? Can you give me some insides about that?
I did not try to run multiple child processes in one windows service, but i tried running two windows services with each a Rhino.Inside. And this does not work.
Even though i do not understand the difference, i will give it a try.
Thanks
I’m having trouble understanding what you are specifically trying to achieve as I don’t understand how a Windows service fits into this conversation. If you could explain a little more about what your goal is, I might be able to help.
It’s a long story but i try to summarize it:
We store our Rhino files in a Product Lifecycle Management tool (short PLM) for all our internal workflows. To provide some more detailed information about the data in the Rhino file (for those who does not have Rhino installed like marketing managers) we export more data like preview images, WebGL visualization files, datasheets, volumes, 3D printing data … and store them also in the PLM to gather as much information as possible or as needed.
This export cannot be done in an interactive session because it would take to long for the user to wait, so we created an application with Rhino.Inside which is started from the PLM whenever new data was uploaded or needs to be processed.
Due to the architecture of the PLM our Rhino.Inside application is started from a windows service as child process.
Now we come to the problem why i created this discussion: this process sometimes takes too long for one process to do all the export even though the computer is not fully utilized (due to single core usage). Therefore i tried to increase performance by starting more than one Rhino.Inside application.
You might want to take a look at the Rhino.Compute architecture.
Rhino.Compute.exe is an executable that launches child compute.geometry.exe processes (Rhino.Inside processes) and forwards requests to these child processes in a round robin scheduling approach. It may not be exactly what you want to use, but it may give you some ideas on what can be done.
I’m assuming you are trying to parallelize the requested tasks to reduce wait time. An export is still going to use a single core, but you could be running multiple exports at the same time with multiple processes.
Is there a specific export type that is taking too long?
Unfortunately there is not a single or a couple of Rhino API calls which we use, there is much more. And all this implementation was done over the years in a C++ plugin. So if we want to use Rhino.Compute we had to rework all this interfaces, exports, etc.
So at the moment i start a Rhino.Inside application and in this session also our plugin is loaded and we just call all existing implementations from within the Rhino.Inside application. And for one process it works, just not as fast as we need.
Maybe i totally miss using Rhino.Inside, but at the moment this was the only solution i found without reworking the whole code.
I interpreted the word export to mean one of the file export formats that we write to; my mistake.
You should be able to create a simple .NET plug-in that exposes new endpoints callable by compute. When the plug-in gets called, it could turn around and call your C++ plug-in. If you want to go that route, we can work with you to figure out a solution.
So as far as i understood my C++ plugin can be loaded in a compute installation, because it’s just another Rhino.Inside application which is hosted, started and and called by a Rhino.Compute server.
Just get me right i want to understand the whole thing to do things right: What would be the difference the way i did it?
At the end a Rhino.Inside application calls the implementation in my C++ plugin, in my way directly from Rhino.Inside, in your way via Rhino.Compute->Compute.Geometry (Rhino.Inside)->.Net Plugin->My C++ Plugin.
The advantage to using compute would be that an instance (or multiple instances) of Rhino.Inside could be up and running all of the time and waiting to process jobs that you send to it. Compute also handles the chores of serializing data to communicate with child processes.
I really only brought this up because it sounds like you are trying to work with multiple processes in order to parallelize multiple tasks. If you can launch multiple child Rhino.Inside applications from your services, you probably don’t need compute.