Is there a good way to run a periodically running background process while the Shotgrid Desktop is running?
I was thinking about starting an async process with time.sleep in an endless loop upon Shotgrid Desktop launch, but I’m not sure where to put the corresponding code, or if there’s a better way to do it.
@Ricardo_Musch Yes, currently I implemented this in the bootstrap core hook (however it runs twice every time for some reason).
It’s not SG related. I’m creating a function that runs in the background and updates the 3rd party packages in the background, so when the user wants to start working, they don’t have to wait for all the package updates to download, because we already downloaded them in the background.
This is mainly to improve productivity.
Of course there are ways to handle this, but bringing in new separated solutions always complicate the system, especially for something so small like this function call.
Does it make toolkit slower though? Since it runs as a separate thread I’d think it doesn’t matter, it’s detached from the main course of the toolkit. I might be wrong, I’m no expert in multithreading neither.
I think this would be nice, because this upgrade makes sure the DCC-s get their dependencies correctly, so I think it’s very much related to the whole SG infrastructure.
Yes, only a few seconds, but that adds to the actual loading time of the DCC, and I would like it to be as fast as possible. And this small background update could carve off seconds every time something is launched. And it’s not just the download time, it’s the package checking and evaluating time too. I know it’s not much, but it could make artists more relaxed and satisfied with their tools, in my opinion… or maybe I’m just generating problems for myself
I’m not sure of what OS you are running on and the general IT structure of your facility but in a Windows Domain environment I would do the following:
Create a Group policy Object with a Scheduled Task
Assign that scheduled task required triggers (i.e. every hour)
Make it run a python script that checks for packages and copies them
Assign it to a bunch of machines
This keeps this function outside the Toolkit pipe which in my opinion is better in this case.
if you really want to trigger this from Toolkit then maybe the context_change core hook is a place for it since it will get triggered loads.
But again, make sure it doesnt hold that up or toolkit will start becoming slow (i.e. clicking a task in the UI of workfiles will fire off your sync)