-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restrict scope of Local Message Transport #37
Comments
Do we need to decide that yet? Can't we design the rest and then look, how much can be "local"? (Single process will work, that we know) Or does anyone require multi process local message transfer? Yes, we have it in mind, and we are able to allow in a single process, therefore we can check "local mode available". |
I would need something for writing #24. But I agree to postpone. I'll find a defensive formulation and add a todo note, and we solve this later. |
Yes, I agree, I think we should work on the DMT stuff, and once that is set up (or at least properly defined), we can include the LMT in-process comms. As for a defensive wording, you could scrap all connections between Node and LMT/DMT, and only put a statement about the LMT/DMT types separately. |
I have put LMT on "notional" status and added notes to that effect. I also only retained queues and zmq inproc in the list of LMT options. |
Closed by #24. |
In #24, Benjamin remarked
My reply:
Originally posted by @bilderbuchi in #24 (comment)
So, to make it easier to specify the network structure, should we limit the scope of LMT to threading queues and zmq inproc ? Both? Either? Something else that should also be added?
The aim is that we restrict LMT locality more than planned, to one process, so the options are ones that work in one process.
The text was updated successfully, but these errors were encountered: