Access Denied while trying to access multiprocessing module

[manharXEA2X]

As the title suggests, I came across this error while trying to access the multiprocessing module from within Fusion 360 (I think when the code was trying to access WinMPI). I have attached a screenshot of the error code. I tried running Fusion as an admin (a general cure-all solution for access-related issues)but to no avail. Is there something I'm missing out on or does Fusion not allow multithreading and multiprocessing capabilities? I did see someone talk about how they managed to import the modules successfully in an older post  but in the answer to that question, the expert replied that the Fusion API uses just the one thread. Is it true for multiple processes as well? The reason I require more than one thread is so that I can generate sweep profiles across multiple arrays of lines which are picked up off a separate data file. I'm not so big on coding yet so simplified solutions and layman terms would be deeply appreciated. TIA!

[BrianEkins · Accepted solution]

With a few exceptions, Fusion is single-threaded. The UI is single-threaded and the API also runs in that same thread. It is possible to do processing that doesn't involve the Fusion API on a separate thread. For example, you need to make some REST calls to gather some information that you'll then use to create a model in Fusion.  The trick here is for the other thread to let your program running in the main thread know it's finished and to pass the information it has collected. The custom event functionality exists in the API for this.  You can read more about it here:

https://help.autodesk.com/view/fusion360/ENU/?guid=GUID-F9FD4A6D-C59F-4176-9003-CE04F7558CCC

[manharXEA2X]

Thanks so much! That is the information I was looking for! Although the fact is that I can still only use the one thread for API functions and methods I guess, so custom events won't do me much good for this purpose (I extensively use the line and sketch methods in the loop which I wish to use). Also, is the worker thread limited by the GIL? In that case, there can only be one worker thread working at a time, right?

[BrianEkins]

I would assume the GIL is in play here since we're working with Python.

[manharXEA2X]

Thanks! I see, so there is only going to be one usable thread. And this is true for the worker and main thread too, right? The add-in main code and the worker script would be using the single thread for interpretation? So I won't exactly be reducing the loading time on fusion, just allowing interleaving capability rather than multitasking ability. I'm sorry if I'm being repetitive.

[BrianEkins]

It's definitely true that the part of Fusion that provided interaction with the user, which also includes the API, is single-threaded. Using multiple threads for work outside of Python is supported by Python but within the limits of the GIL.  I haven't played with it much because in my experience there's no advantage in what I do so I don't have much personal experience. 

[manharXEA2X]

Thanks for the info! I'll wait for someone who has tried it to provide more insight, or I'll put it up myself if I stumble upon something.