Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: Subkernel exception fix #2458

Merged
merged 1 commit into from
Jul 31, 2024

Conversation

architeuthidae
Copy link
Collaborator

ARTIQ Pull Request

Description of Changes

To match #2455 :)

Related Issue

Type of Changes

Type
βœ“ πŸ“œ Docs

Steps (Choose relevant, delete irrelevant before submitting)

All Pull Requests

  • Use correct spelling and grammar.

Documentation Changes

  • Check, test, and update the documentation in doc/. Build documentation (cd doc/manual/; make html) to ensure no errors.

Licensing

See copyright & licensing for more info.
ARTIQ files that do not contain a license header are copyrighted by M-Labs Limited and are licensed under LGPLv3+.

@@ -178,6 +177,9 @@ In this case, without the preload, the delay after the core reset would need to
.. note::
Subkernels can call subkernels on any other satellite, not only their own. Care should however be taken that different kernels do not call subkernels on the same satellite, or only very cautiously. If, e.g., a newer call overrides a subkernel that another caller is awaiting, unpredictable timeouts or locks may result, as the original subkernel will never return. There is not currently any mechanism to check whether a particular satellite is 'busy'; it is up to the programmer to handle this correctly.

.. note::
Exceptions raised by a subkernel can be caught by the originating subkernel, the master kernel (if awaited), or propagated to the host. This applies even when the subkernel was called by another subkernel, e.g. (``kernel -> subkernel_1 -> subkernel_2``). An exception in ``subkernel_2`` is sent straight to the master device and cannot be caught by ``subkernel_1``.
Copy link
Collaborator

@Spaqin Spaqin Jun 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is sent triple space

This behavior may be changed in future (up for potential discussion) though... but OK for now

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh how odd. Fixed

Subkernels can call subkernels on any other satellite, not only their own. Care should however be taken that different kernels do not call subkernels on the same satellite, or only very cautiously. If, e.g., a newer call overrides a subkernel that another caller is awaiting, unpredictable timeouts or locks may result, as the original subkernel will never return. There is not currently any mechanism to check whether a particular satellite is 'busy'; it is up to the programmer to handle this correctly.

.. note::
Exceptions raised by a subkernel can be caught by the originating subkernel, the master kernel (if awaited), or propagated to the host. This applies even when the subkernel was called by another subkernel, e.g. (``kernel -> subkernel_1 -> subkernel_2``). An exception in ``subkernel_2`` is sent straight to the master device and cannot be caught by ``subkernel_1``.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With recent changes to #2455 it's not true anymore, subkernels may catch exceptions raised by further subkernels now too.

@architeuthidae
Copy link
Collaborator Author

Rebased for merge conflict

@sbourdeauducq sbourdeauducq merged commit 0623480 into m-labs:master Jul 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants