CAD-3243: trace-forward library.

[denisshevchenko]

This is trace-forward library: typed-protocols-based library allowing to forward tracing items from one process to another one. This is the first step toward a new tracing infrastructure (please see #2847). The trace-dispatcher will use this library to forward TraceObjects to external acceptors (for example, cardano-tracer).

You can think of this library as a replacement for old plugins trace-forwarder and trace-acceptor from iohk-monitoring-framework.

[deepfire]

LGTM!

It's great to finally have things moving towards the final merge!

[denisshevchenko]

@newhoggy Thanks! Fixed.

[Jimbo4350]

One minor addition and then I'm happy to approve

[coot]

LGTM, @denisshevchenko thanks for cooperation!

[denisshevchenko]

bors merge

[deepfire]

bors r-

[iohk-bors]

Canceled.

[deepfire]

Marcin has one last question.

[coot]

This is not do what I asked for. I wanted the whole acceptActions to terminate if the IORef is set to true and does not terminate within a timeout, now it will timeout the niHandler action but it has nothing to do with the IORef.

[coot]

I'd suggest to turn the IORef into a TVar and use it in runActionWithTimer. It will require two stm transactions first would block on on this tvar. Then one can create a timerVar and block on it, something like this:

timeoutWhenStopped :: TVar Bool -> Int -> IO a -> IO (Maybe a)
timeoutWhenStoppepd stopVar delay io =
  fmap (either Just (\_ -> Nothing)) $
  race io
     $ do atomically (readTVar stopVar >>= check)
          v <- registerDealay delay    
          atomically (readTVar v >>= check)       

You cannot apply it to TraceAcceptor type directly, since it's not an IO action, but you can plug it where you run the acceptor using runPeer.

[deepfire]

@coot, what you are alluding to is quite involved -- can you suggest a concrete change -- we'll be happy to accept.

[coot]

The biggest change is IORef -> TVar, but it's a mechanical change - so quite easy to do. Other than that it's just wrapping runPeer inside timeoutWhenStopped.

[denisshevchenko]

TVar instead of IORef is already done: https://github.com/input-output-hk/cardano-node/blob/c6f8f7555993cf31c8a63906ef42ce4dad6a6118/trace-forward/src/Trace/Forward/Network/Acceptor.hs#L168

[denisshevchenko]

wrapping runPeer inside timeoutWhenStopped

Honestly, I cannot understand why?? I do understand why we need stop timer - to avoid too long (theoretically - infinite) time for performing of external handlers. And now it's STM-transactions with orElse - ok, I understand. But why do we need to wrap runPeer inside timeoutWhenStopped? runPeer calls acceptorActions, acceptorActions calls runActionWithTimer...

[coot]

Peer, which is a result of calling acceptorActions is just a data type, you cannot effectively limit how long it will execute after the stop var was set to True, or do any other resource handling. You can only do that around runPeer which returns an IO action, IO actions can be timed out.

[denisshevchenko]

Ok. But I still don't understand how to do it exactly. Are there any existing typed-protocols in ouroboros-network where I can find an example of it? And does any from existing protocols have such a TVar-based stopping mechanism?

Yes, my level isn't very high: I'm not deeply familiar with STM, I don't deeply understand typed-protocol inside and did a lot of things just by example. Sorry, it's true. And I took responsibility for trace-forward not because I'm the best person for it, but because we don't have another person for it... That's why existing example would be the best option for me.

[denisshevchenko]

bors r+

[iohk-bors]

Build succeeded:

• ci/hydra-eval
• ci/hydra-build:required
• buildkite/cardano-node