* Feature: support for shared downloads directory
This feature is especially relevant for users with several clients running simultaneously within the same computer (computers running several GPUs or any combination of GPUs + CPUs) or multiple computers running in a network. The feature allows the user to specify a shared downloads directory via the new -shared-downloads-dir client option. All the clients using that option will share the same binaries and scene files.
How it works?
The first client downloading a binary or scene will save the file in the directory especified in -shared-downloads-directory. The rest of the clients using the same option will wait until the file has been downloaded. Once the file has been downloaded, it will be ready for the rest of the clients.
This feature is especially relevant for users with metered/slow connections or multiple computers/clients that don't want to download the same binary/file multiple times.
IMPORTANT: All the clients intended to share the binaries and scenes must execute the client with the same -shared-downloads-dir parameter.
The text UI gets quite messy during the render process, as it takes at least one extra line of the screen per second. This PR fixes that issue and also shows an ASCII bar to show the render progress.
As the value of the askForRendererKill flag is set right after the return of the kill process, under some particular memory and system load circumstances, a race condition occurs and the rendering process in the main thread is closed faster than the process.destroy() returns the control to the thread the called the OS.getOS().kill(process.getProcess()) method. If that condition occurs, the isAskForRendererKill() check returns false (the flag hasn't been set to True in the separate thread) and the execution continues with the frame output check (that doesn't exist as the rendering process was interrupted). The final outcome is a wrong NO_FILE_OUTPUT error instead of the proper RENDERER_KILLED_BY_USER_OVER_TIME.
The fix has been setting the askForRendererKill flag to true before the process is destroyed. If the racing condition occurs, the askForRendererKill will be correctly set.
When sending Ctrl+C to the terminal it also get's sent to all subprocesses e.g. also the render process.
The java program handles Ctrl+C but the renderer quits on Ctrl+C
This script causes the renderer to ignore Ctrl+C.
DaCool