`Kernel._control_lock` created after it may be used

Il problema si trova in ipykernel/kernelbase.py intorno alla riga 347, dove si accede a _control_lock prima che venga inizializzato. Controlla il metodo __init__ della classe kernel per vedere dove viene impostato _control_lock. La soluzione consiste nell'assicurarsi che il lock venga creato prima che vengano inviati messaggi di controllo. Controlla il branch collegato come riferimento per la patch, quindi verifica eseguendo il kernel in un ambiente simulato ad alta latenza.

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.