You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As people start to use maelstrom, we're going to want to have an easy way for them to try it out. A lot of people won't have other machines on which to run a broker and worker. Some thoughts:
It would be cool if you could just run cargo maelstrom run in some sort of standalone mode. The broker and worker would last only until the client finished executing.
In its most basic incarnation, this could just start up the broker and worker as separate processes. But that would be less than ideal from an efficiency point of view. Another option would be to cut the broker out entirely and have a specialized worker that the client would submit to immediately.
If we had a fuse-based worker, then we could just have a different fuse implementation that fulfilled the file system requests from the files specified in the client's manifest. This might involve copying some files around, or better yet hard-linking them. If we had a overlayfs-based worker, we'd have to create the various layers, again maybe by doing some hardlinking.
As covered elsewhere. We may want to be able to have a local worker for other reasons.
The text was updated successfully, but these errors were encountered:
As people start to use maelstrom, we're going to want to have an easy way for them to try it out. A lot of people won't have other machines on which to run a broker and worker. Some thoughts:
cargo maelstrom run
in some sort of standalone mode. The broker and worker would last only until the client finished executing.The text was updated successfully, but these errors were encountered: