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
Currently the progress loop runs both HG_Progress and HG_Trigger. When mixing Margo with pure-Mercury RPCs, this forces these RPCs to run in the context of the progress loop because they are not submitted as ULTs to RPC pools.
The solution would be to have a trigger_thread_count parameter in Margo, which would tell Margo to create a specified number of new ES, each running a ULT blocking on HG_Trigger. If trigger_thread_count=0 (default), HG_Trigger would be called in the context of the progress loop.
Note: Because HG_Trigger blocks in a way that will not yield to other ULTs, these extra ES should not be used to schedule work other than the trigger ULT (technically these extra ES could well be pthreads instead of ES, but I find it cleaner to use ES).
The text was updated successfully, but these errors were encountered:
Currently the progress loop runs both
HG_Progress
andHG_Trigger
. When mixing Margo with pure-Mercury RPCs, this forces these RPCs to run in the context of the progress loop because they are not submitted as ULTs to RPC pools.The solution would be to have a
trigger_thread_count
parameter in Margo, which would tell Margo to create a specified number of new ES, each running a ULT blocking onHG_Trigger
. Iftrigger_thread_count=0
(default),HG_Trigger
would be called in the context of the progress loop.Note: Because
HG_Trigger
blocks in a way that will not yield to other ULTs, these extra ES should not be used to schedule work other than the trigger ULT (technically these extra ES could well be pthreads instead of ES, but I find it cleaner to use ES).The text was updated successfully, but these errors were encountered: