Instruments and servers.

@qdev-dk/qcodes
I would like to hear your opinion on the following.

But first, let's define things :

• A server is just a piece of software than can listen/answer to something
  • note: this has nothing to do with threads/processes
• A process provides the resources needed to execute some code . A process has a virtual address space, executable code, open handles to system objects, a security context, a unique process identifier, environment variables, and at least one thread of execution.
• A thread is an entity within a process that can be scheduled for execution. All threads of a process share its virtual address space and system resources.
• GIL, because of this python can't use more than 1 core using threads.
  • note: this means that CPU bound tasks can be only and only possibly creating a new python interpreter on a new OS process.
  • note: creating new OS processes is expensive both in term of speed and memory.

Questions

• Why should an instrument be its own server ?
• Why should two or more instruments sit in one server?
• Does an instrument need to live in its own process ?

No files, tests, or entry points are named. Start by reviewing the current instrument and server architecture, then seek a maintainer decision on the three deployment questions; the issue is complete only when the intended architecture and scope are agreed.