Remove the pipe protocol compiler #3658
Comments
|
In practice I don't think we've even transitioned off Channels and Ports terribly much yet, much less given this stuff a fair shake. I'd like to give this more bake time to see which parts are necessary, which parts overcomplex. We haven't written enough complex concurrent code yet to be clear on that yet. There are a lot of moderately-complex protocols I can imagine us wanting to have implementations for (those related to I/O, files, sockets, locks, databases, concurrency primitives) that it may be the best route for generating. Doesn't feel clear to me yet. |
|
:( |
|
I'm still in favor of this. pipec continues to be difficult to maintain. Every time I work with or on pipes I am tempted to inline the |
|
Not critical for 0.6, de-milestoning |
The pipes compiler produced data types that encoded efficient and safe bounded message passing protocols between two endpoints. It was also capable of producing unbounded protocols. It was useful research but was arguably done before its proper time. I am removing it for the following reasons: * In practice we used it only for producing the `oneshot` protcol and the unbounded `stream` protocol and all communication in Rust use those. * The interface between the proto! macro and the standard library has a large surface area and was difficult to maintain through language and library changes. * It is now written in an old dialect of Rust and generates code which would likely be considered non-idiomatic. * Both the compiler and the runtime are difficult to understand, and likewise the relationship between the generated code and the library is hard to understand. Debugging is difficult. * The new scheduler implements `stream` and `oneshot` by hand in a way that will be significantly easier to maintain. This shouldn't be taken as an indication that 'channel protocols' for Rust are not worth pursuing again in the future. Concerned parties may include: @graydon, @pcwalton, @eholk, @bblum The most likely candidates for closing are #7666, #3018, #3020, #7021, #7667, #7303, #3658, #3295.
Abstractions built on pipes are created using a 'protocol compiler' that can define complex interactions between two endpoints. At this point I think it is not worth maintaining, for several reasons:
Instead I think we should rewrite the existing protocols by hand and remove the compiler.
The text was updated successfully, but these errors were encountered: