From b8325e0c60cd47c78201c92b539ee9180a6cea5b Mon Sep 17 00:00:00 2001 From: Duncan Coutts Date: Sat, 15 Feb 2020 13:54:43 +0100 Subject: [PATCH] Disable the on-demand start of mini-protocol threads for now Fixes issue #1646 The problem, we realised, is that which peer initiates the overall mux bearer is actually independent from whether protocol threads should be started on-demand or started eagerly. What it really depends on is which peer has agency in the initial protocol state. For most mini-protocols it is the peer that initiated the bearer that has agency in the initial state, but that is not true for all protocols, and in particular for the TxSubmission protocol in ouroboros-network. The solution will be to make the on-demand vs eager distinction independent of the initiator vs responder distinction, and have it be specified in the MuxMiniProtocol. We missed this in the network-mux and ouroboros-network tests because we did not have bundles of mini-protocols with mixed initial agency. This should be corrected. --- network-mux/src/Network/Mux.hs | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/network-mux/src/Network/Mux.hs b/network-mux/src/Network/Mux.hs index 0ebef7f859b..f6e2e3b2e0b 100644 --- a/network-mux/src/Network/Mux.hs +++ b/network-mux/src/Network/Mux.hs @@ -115,6 +115,8 @@ muxStart tracer (MuxApplication ptcls) bearer = do : demuxerJob dispatchtbl : catMaybes [ miniProtocolInitiatorJob cnt tq ptcl pix initQ respQ | (pix, (ptcl, initQ, respQ)) <- zip [0..] ptcls' ] + ++ catMaybes [ miniProtocolResponderJob cnt tq ptcl pix initQ respQ + | (pix, (ptcl, initQ, respQ)) <- zip [0..] ptcls' ] respondertbl = setupResponderTable [ miniProtocolResponderJob cnt tq ptcl pix initQ respQ @@ -260,7 +262,15 @@ monitor :: forall m. (MonadSTM m, MonadAsync m, MonadMask m) monitor tracer jobpool (MiniProtocolDispatch _ dispatchtbl) (MiniProtocolResponders respondertbl) = - go (Set.fromList . range . bounds $ respondertbl) + go Set.empty +-- TODO: for the moment on-demand starting is disabled and all mini-protocol +-- threads are started eagerly. Doing this properly involves distinguishing +-- between on-demand and eager mini-protocols, but doing so independently of +-- whether overall we established the bearer as an initiator or as a responder. +-- The on-demand vs eager distinction can be derived from which peer(s) have +-- agency in the initial state of each mini-protocol. +-- +-- go (Set.fromList . range . bounds $ respondertbl) where -- To do this second job it needs to keep track of which responder protocol -- threads are running.