netty-like channels
Summary: I wanted some foundational abstractions to start building out codecs on top of. I also know that Blake gets very amused when I shamelessly copy Java/Netty abstractions, and I live to amuse Blake so I did it again. So here's an implementation of something very similar to Netty's ChannelAdapters/ChannelPipelines Only read() and write() for now, everything/anything else can easily be bolted on once the design is settled (if this is at all the direction we want to go) I have a lot of thoughts about this design but I'm going to save my fingers and leave that to ad hoc discussions once folks take a look at this A couple of things, though: - It should be possible to dynamically add handlers to the chain. How I envision this working is that each original adapters keeps two lists of shared/unique ptrs to adapters of the correct type to sit next to them on either side, and dispatch to them appropriately when they're there. - I was trying to do without separate ChannelHandlerContext objects altogether (keep the interface, but have ChannelPipeline act as the context itself) but ran into issues with virtual multiple inheritance. I might have another go at this. - Only movable types are permitted. I hope this won't be too restrictive, because it would be a PITA to support both move-only and copy-only types. - Why no Rx? Seems to me that any handlers that actually needs Rx (e.g. stats fanout or something) can deal with it themselves. - If it turned out to be useful to nest these (for more flexible composition) that would also be doable. i.e. ChannelPipeline<ChannelPipeline<Handler1, Handler2>, ChannelPipeline<Handler3, Handler4>> Test Plan: super basic test compiles and runs as expected Reviewed By: davejwatson@fb.com Subscribers: ajitb, folly-diffs@, ldbrandy, trunkagent, fugalh, njormrod FB internal diff: D1604575 Tasks: 5002299 Signature: t1:1604575:1415034767:bc3b12fae726890aa6a55ed391286917ae23e56e
Showing
Please register or sign in to comment