-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Open
Labels
T-langRelevant to the language team, which will review and decide on the RFC.Relevant to the language team, which will review and decide on the RFC.T-libs-apiRelevant to the library API team, which will review and decide on the RFC.Relevant to the library API team, which will review and decide on the RFC.
Description
Rust basically is very strong for parallel programming. If Rust supports Serializable Lambda expression, it would be very strong even for distributed programming.
Here was a little discussion.
rust-lang/rust#23759
Python and Java 8 already have similar concepts as follows:
Rufflewind, krzkaczor, nathankleyn, yilongli, andygrove and 3 more
Metadata
Metadata
Assignees
Labels
T-langRelevant to the language team, which will review and decide on the RFC.Relevant to the language team, which will review and decide on the RFC.T-libs-apiRelevant to the library API team, which will review and decide on the RFC.Relevant to the library API team, which will review and decide on the RFC.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
kmcallister commentedon Dec 30, 2015
See also #668.
Rufflewind commentedon Mar 13, 2017
One could do add some compiler magic to support arbitrary object serialization in Rust, with the caveat that such an object can only be deserialized by the same program. This would be like
Any
with persistence. The Haskell recently added support for these kinds of “static pointers”.But the downside of this is that the user has no control over the serialization protocol, and it would require making a serializer that works over arbitrarily complicated types, even though much of it could be done outside of the standard library.
A more flexible approach would be to expose two new mechanisms to Rust:
The ability to have an extensible lookup table for a selection of types, a “global type registry” if you will. This I think is the main missing ingredient for Encodable trait objects #668.
The ability to construct and deconstruct closures into a tuple of its upvars (
Closure::Data
). Typically,Closure::Data
would be serializable through a#[derive]
mechanism.Edit: no need store a separate function pointer since the closure type itself would suffice.
ariesdevil commentedon Jun 20, 2018
Any updates on it? With write spark like system in rust,
Serializable Lambda expression
is needed.habnabit commentedon Jun 26, 2018
(python's pickle does not serialize functions' code to a wire format; it only serializes the name of a function.)
ariesdevil commentedon Jun 26, 2018
@habnabit but you can implement it easier,see https://github.com/douban/dpark/blob/0.5.0/dpark/serialize.py#L250
alecmocatta commentedon Nov 2, 2019
I created a crate
serde_closure
that makes closures serializable by wrapping them with the macroFn!(...)
.If the resulting serializable closure is upcast to
Box<dyn serde_traitobject::Fn()>
it can then be serialized and sent between identical distributed processes usingserde_traitobject
, though this currently requires nightly.Rufflewind commentedon Nov 2, 2019
Interesting. I had tried a similar idea a while back but deemed it too questionable for production use.
alecmocatta commentedon Nov 5, 2019
@Rufflewind Yes, thanks for your crate, it was good inspiration for serde_traitobject.
I just made a rust PR that would make serde_traitobject safe: rust-lang/rust#66113. Keen to hear if you have any thoughts!
#[distributed_slice]
aka a method to enumerate tests rust-lang/testing-devex-team#3