Parallel local qudi sessions

Neverhorst commented 1 year ago

Description

This small PR will allow to run multiple local qudi sessions in parallel.

Motivation and Context

The rotating file handler of the qudi logging facility has prevented this before due to file access conflicts. Now the qudi logger will detect if the log file is already owned by another qudi process and create a new file with a running session index in the name.

However the user must ensure each instance of qudi is running with a different namespace (and remote modules) socket server address configured in order to avoid conflicts.

How Has This Been Tested?

Dummy modules windows 10 Pro 21H2 (build 19044.2130)

Types of changes

[ ] Bug fix
[x] New feature
[ ] Breaking change (Causes existing functionality to not work as expected)

Checklist:

[x] My code follows the code style of this project.
[x] I have documented my changes in /docs/changelog.md.
[ ] My change requires additional/updated documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added/updated the config example for any module docstrings as necessary.
[x] I have checked that the change does not contain obvious errors (syntax, indentation, mutable default values, etc.).
[x] I have tested my changes using 'Load all modules' on the default dummy configuration.
[x] All changed Jupyter notebooks have been stripped of their output cells.

kay-jahnke commented 1 year ago

Tested in Win10 Pro 21H2, with python 3.8.

In principle it works fine now to start qudi twice. If both qudi instances load the same config (which they do by default) or if different configs have the same ports configured for rpyc, this causes the following error (qudi starts nonetheless and the console window works): grafik

Not sure if this actually a bug but rather the intended behavior when using the same port.

Neverhorst commented 1 year ago

Tested in Win10 Pro 21H2, with python 3.8.

In principle it works fine now to start qudi twice. If both qudi instances load the same config (which they do by default) or if different configs have the same ports configured for rpyc, this causes the following error (qudi starts nonetheless and the console window works):

Not sure if this actually a bug but rather the intended behavior when using the same port.

You can not use the same port for different servers, that's why I mentioned this in the PR comments and changelog. It's the user responsibility to load a separate config for each qudi instance with separate ports, e.g. by running qudi with the --config argument.

Neverhorst commented 1 year ago

And the "working" console in the error case you mentioned @kay-jahnke is actually interfacing with the first started qudi instance. (as can be seen in the log of the first started instance... something like "client connected...".

Ulm-IQO / qudi-core