4 ms·

Glad to see another option out there for file sync. Browsing the FAQ I noticed: To further limit the amount of CPU used when syncing and scanning, set the env

Glad to see another option out there for file sync. Browsing the FAQ I noticed: To further limit the amount of CPU used when syncing and scanning, set the environment variable GOMAXPROCS to the maximum number of CPU cores Syncthing should use Are they using an environment variable shared by other Go programs? Seems like bad practice... why aren't they using a variable or or switch that's unique to Syncthing instead?

hparadiz 5y ago
It's a GO runtime setting. Has nothing to do with Syncthing.
- rkagerer 5y ago
  I'm not a Go programmer, but couldn't they achieve the same thing without name collision by reading a custom environment variable at startup and setting runtime.GOMAXPROCS?
  - vetinari 5y ago
    Why would they do it? This setting is managed by Go runtime, and Go runtime defines a specific env var for customization. If you want different setting for different Go programs, no problem, it is not a global config, but per process, so set the env var to desired value only for syncthing process.
fps_doug 5y ago
> Are they using an environment variable shared by other Go prpgrams? Seems like bad practice... Huh? So only set it for syncthing.
- rkagerer 5y ago
  Easy on Linux, not so much (and messier) on Windows.
OriginalPenguin 5y ago
If you want to set it just for syncthing, just type this when you run it from the command line: GOMAXPROCS=2 syncthing
yarcob 5y ago
If you would use that variable, you wouldn't set it globally. You would set it only for the syncthing process. For example, when you use systemd to run syncthing, you can configure the environment for syncthing in the unit file. Other Go programs on your machine won't be affected.
- rkagerer 5y ago
  I wonder if my annoyance stems from a difference between Windows vs. Linux conventions? I hark back to when environment variables were set globally on a machine (back in DOS days). I realize NTVDM emulation introduced the ability to configure more granular ones (eg. system vs. user) and you can now create a shortcut[1] that launches an intermediate step which tailors the environment for a single process. But always viewed that as a cludgey convenience for users, not a design paradigm for developers. (Also with at least six[2] different places to check for where Windows envvars come from, I typically favor the expliciteness of command line switches). What happens if someone's creating a script that will shell out simultaneously to multiple Go programs? Do they all inherit the parent's environment variables? Does the script now have to tailor the same-named variable for each one? Am I doing something wrong or is this easier on Linux and us Windows schmucks got left behind? Thanks for any elucidation... [1] https://stackoverflow.com/questions/3036325/can-i-set-an-environment-variable-for-an-application-using-a-shortcut-in-windows https://stackoverflow.com/questions/3036325/can-i-set-an-env... [2] https://flylib.com/books/en/4.53.1.59/1/#:~:text=Environment%20variables%20can%20be%20set%20in%20any%20of%20six%20places https://flylib.com/books/en/4.53.1.59/1/#:~:text=Environment...
  - yarcob 5y ago
    > What happens if someone's creating a script that will shell out simultaneously to multiple Go programs? Do they all inherit the parent's environment variables? By default, every process inherits the environment of its parent process. So if you set an environment variable (eg. with the EXPORT command in bash), then every process you launch from the shell will have the same value for the environment variable. However, you can set environment variables for each command that you execute. So for example in a shell script you could do something like this: # set the environment variables value to 4 # valid for all subsequently executed commands export GOMAXPROCS=4 # run syncthing but limit it to 2 processors # defining the variable like this it will only affect this command GOMAXPROCS=2 /usr/local/bin/syncthing # run some other go program # the environment var will be set to the value 4 again /usr/local/bin/other-go-program The beauty of using environment variables is that they are much more flexible than command line options. For example, assume I execute a script from someone else, who did not set GOMAXPROCS. Then I could just set the GOMAXPROCS variable and then execute the script. I could change the config without needing to edit the script!

hparadiz 5y ago

It's a GO runtime setting. Has nothing to do with Syncthing.

rkagerer 5y ago
I'm not a Go programmer, but couldn't they achieve the same thing without name collision by reading a custom environment variable at startup and setting runtime.GOMAXPROCS?
- vetinari 5y ago
  Why would they do it? This setting is managed by Go runtime, and Go runtime defines a specific env var for customization. If you want different setting for different Go programs, no problem, it is not a global config, but per process, so set the env var to desired value only for syncthing process.

fps_doug 5y ago

> Are they using an environment variable shared by other Go prpgrams? Seems like bad practice... Huh? So only set it for syncthing.

rkagerer 5y ago
Easy on Linux, not so much (and messier) on Windows.

OriginalPenguin 5y ago

If you want to set it just for syncthing, just type this when you run it from the command line: GOMAXPROCS=2 syncthing

yarcob 5y ago

If you would use that variable, you wouldn't set it globally. You would set it only for the syncthing process. For example, when you use systemd to run syncthing, you can configure the environment for syncthing in the unit file. Other Go programs on your machine won't be affected.

rkagerer 5y ago
I wonder if my annoyance stems from a difference between Windows vs. Linux conventions? I hark back to when environment variables were set globally on a machine (back in DOS days). I realize NTVDM emulation introduced the ability to configure more granular ones (eg. system vs. user) and you can now create a shortcut[1] that launches an intermediate step which tailors the environment for a single process. But always viewed that as a cludgey convenience for users, not a design paradigm for developers. (Also with at least six[2] different places to check for where Windows envvars come from, I typically favor the expliciteness of command line switches). What happens if someone's creating a script that will shell out simultaneously to multiple Go programs? Do they all inherit the parent's environment variables? Does the script now have to tailor the same-named variable for each one? Am I doing something wrong or is this easier on Linux and us Windows schmucks got left behind? Thanks for any elucidation... [1] https://stackoverflow.com/questions/3036325/can-i-set-an-environment-variable-for-an-application-using-a-shortcut-in-windows https://stackoverflow.com/questions/3036325/can-i-set-an-env... [2] https://flylib.com/books/en/4.53.1.59/1/#:~:text=Environment%20variables%20can%20be%20set%20in%20any%20of%20six%20places https://flylib.com/books/en/4.53.1.59/1/#:~:text=Environment...
- yarcob 5y ago
  > What happens if someone's creating a script that will shell out simultaneously to multiple Go programs? Do they all inherit the parent's environment variables? By default, every process inherits the environment of its parent process. So if you set an environment variable (eg. with the EXPORT command in bash), then every process you launch from the shell will have the same value for the environment variable. However, you can set environment variables for each command that you execute. So for example in a shell script you could do something like this: # set the environment variables value to 4 # valid for all subsequently executed commands export GOMAXPROCS=4 # run syncthing but limit it to 2 processors # defining the variable like this it will only affect this command GOMAXPROCS=2 /usr/local/bin/syncthing # run some other go program # the environment var will be set to the value 4 again /usr/local/bin/other-go-program The beauty of using environment variables is that they are much more flexible than command line options. For example, assume I execute a script from someone else, who did not set GOMAXPROCS. Then I could just set the GOMAXPROCS variable and then execute the script. I could change the config without needing to edit the script!