You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we require that callbacks be completed on a different thread in order to resolve issues that can arise when the callback cannot be executed on the same thread as the submitter. For example, the submitting thread might be holding a lock that the callback will need to acquire to perform it's job. That would result in a deadlock, and as a safeguard we have ensured that the callback is always executed on a separate thread. Sometimes we could avoid this. Some thoughts:
a) Allow consumers to register a "reentrant" version of the callback or indicate that the callback is reentrant. This may require some extra signaling to the callback to indicate when the thread is the same as the submitter. This could be passed in via a function argument, a flag in the aio, or simply by requiring the calling thread to check the thread id. The last of this is probably the least desirable from a usability standpoint.
b) If we keep track of the thread id, we could also then recognize when the submitting thread differs from the thread calling nni_aio_finish, and complete it synchronously.
c) We could combine both a & c, meaning that asynchronous completions should indeed become rather uncommon. This is likely to have a dramatic impact on the average latency and scalability of NNG.
And none of this needs to be particularly difficult or risky to implement.
The text was updated successfully, but these errors were encountered:
Right now we require that callbacks be completed on a different thread in order to resolve issues that can arise when the callback cannot be executed on the same thread as the submitter. For example, the submitting thread might be holding a lock that the callback will need to acquire to perform it's job. That would result in a deadlock, and as a safeguard we have ensured that the callback is always executed on a separate thread. Sometimes we could avoid this. Some thoughts:
a) Allow consumers to register a "reentrant" version of the callback or indicate that the callback is reentrant. This may require some extra signaling to the callback to indicate when the thread is the same as the submitter. This could be passed in via a function argument, a flag in the aio, or simply by requiring the calling thread to check the thread id. The last of this is probably the least desirable from a usability standpoint.
b) If we keep track of the thread id, we could also then recognize when the submitting thread differs from the thread calling nni_aio_finish, and complete it synchronously.
c) We could combine both a & c, meaning that asynchronous completions should indeed become rather uncommon. This is likely to have a dramatic impact on the average latency and scalability of NNG.
And none of this needs to be particularly difficult or risky to implement.
The text was updated successfully, but these errors were encountered: