-
Notifications
You must be signed in to change notification settings - Fork 193
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
Conversation
@@ -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``. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh how odd. Fixed
9aa4ad8
to
c7f4449
Compare
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``. |
There was a problem hiding this comment.
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.
c7f4449
to
b1d88e3
Compare
b1d88e3
to
eddfde5
Compare
Rebased for merge conflict |
ARTIQ Pull Request
Description of Changes
To match #2455 :)
Related Issue
Type of Changes
Steps (Choose relevant, delete irrelevant before submitting)
All Pull Requests
Documentation Changes
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+.