`Kernel._control_lock` created after it may be used

Le problème se situe dans ipykernel/kernelbase.py vers la ligne 347, où _control_lock est accédé avant d'être initialisé. Examinez la méthode __init__ de la classe kernel pour voir où _control_lock est défini. La correction consiste à s'assurer que le verrou est créé avant que tout message de contrôle ne soit distribué. Consultez la branche liée comme référence pour le correctif, puis vérifiez en exécutant le noyau dans un environnement simulé à haute latence.

I ran into the following exception when running a Notebook inside VSCode with the python environment running on a remote machine (through the VSCode tunnel). The remote machine has a distributed file system which can cause significant latencies when starting a notebook from scratch, which can unearth race conditions that would be unlikely on a normal laptop or desktop machine. I guess our somewhat offbeat use case is the reason this did not get noticed before.

ERROR:tornado.general:Uncaught exception in ZMQStream callback
Traceback (most recent call last):
  File "/apps/gent/RHEL9/cascadelake-ib/software/IPython/9.14.0-GCCcore-15.2.0/lib/python3.14/site-packages/traitlets/traitlets.py", line 651, in get
    value = obj._trait_values[self.name]
            ~~~~~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: '_control_lock'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/apps/gent/RHEL9/cascadelake-ib/software/PyZMQ/27.1.0-GCCcore-15.2.0/lib/python3.14/site-packages/zmq/eventloop/zmqstream.py", line 565, in _log_error
    f.result()
    ~~~~~~~~^^
  File "/apps/gent/RHEL9/cascadelake-ib/software/jupyter-server/2.19.0-GCCcore-15.2.0/lib/python3.14/site-packages/ipykernel/kernelbase.py", line 347, in dispatch_control
    async with self._control_lock:
               ^^^^^^^^^^^^^^^^^^
  File "/apps/gent/RHEL9/cascadelake-ib/software/IPython/9.14.0-GCCcore-15.2.0/lib/python3.14/site-packages/traitlets/traitlets.py", line 706, in __get__
    return self.get(obj, cls)  # type:ignore[return-value]
           ~~~~~~~~^^^^^^^^^^
  File "/apps/gent/RHEL9/cascadelake-ib/software/IPython/9.14.0-GCCcore-15.2.0/lib/python3.14/site-packages/traitlets/traitlets.py", line 668, in get
    value = self._validate(obj, default)
  File "/apps/gent/RHEL9/cascadelake-ib/software/IPython/9.14.0-GCCcore-15.2.0/lib/python3.14/site-packages/traitlets/traitlets.py", line 741, in _validate
    value = self.validate(obj, value)
  File "/apps/gent/RHEL9/cascadelake-ib/software/IPython/9.14.0-GCCcore-15.2.0/lib/python3.14/site-packages/traitlets/traitlets.py", line 2319, in validate
    self.error(obj, value)
    ~~~~~~~~~~^^^^^^^^^^^^
  File "/apps/gent/RHEL9/cascadelake-ib/software/IPython/9.14.0-GCCcore-15.2.0/lib/python3.14/site-packages/traitlets/traitlets.py", line 850, in error
    raise TraitError(e)
traitlets.traitlets.TraitError: The '_control_lock' trait of an IPythonKernel instance expected a Lock, not the NoneType None.

This was with ipykernel v7.2.0 on Redhat Linux 9 (remote machine, HPC infrastructure). I've written a patch for v7.2.0, so we can perform a minimal upgrade of our teaching setup:

https://github.com/tovrstra/ipykernel/tree/bugfix/control_lock_race

I think the same issue (_control_lock created too late) is still present in the main branch. I'll make a PR on the main branch in minute.