Revise Config and fix various things #99
Conversation
| @@ -70,7 +95,8 @@ impl Config { | |||
| Self { | |||
| name: "my rto".to_owned(), | |||
| call_slots: 512, | |||
| call_timeout: std::time::Duration::from_millis(1000), | |||
| maximum_services_num: 65536, | |||
There was a problem hiding this comment.
Isn't it more common to 65535 as a maximum value rather than 65536?
I thought 65535 is better because it is u16::MAX https://doc.rust-lang.org/std/primitive.u16.html#associatedconstant.MAX
It is not an important comment. I want to know in which point 65536 is better.
There was a problem hiding this comment.
That makes sense. I'll fix
There was a problem hiding this comment.
Well I thought about it, but it's common to use 2^N instead of 2^N-1 for a size of something, not index.
| /// Number of the maximum of concurrent calls. | ||
| /// | ||
| /// Value of this doesn't have anything to do with the number of threads that would be spawned. | ||
| /// Having a large number of this wouldn't charge any cost except really small additional memory allocation. | ||
| /// | ||
| /// [`server_threads`]: ./struct.Config.html#field.server_threads | ||
| pub call_slots: usize, |
There was a problem hiding this comment.
If this value is not important, we may use a Vec to save slots and make it scale automatically(Or give an enough default value).
Providing a not important option makes the system difficult to use.
You don't need to fix it right now. Please consider it.
There was a problem hiding this comment.
Ok. Let's keep the parameters as raw as possible for now, for easy debug/test at least.
We might provide more high level interface to setup a parameter later
| /// A maximum number of services that this context can export. | ||
| pub maximum_services_num: usize, |
There was a problem hiding this comment.
I think it's subtle to provide this as an option.
It may hard to predict what will be a good maximum service number.
I don't know what will be a good maximum_services_num value when I implement Foundry modules. However small maximum_services_num may make a deadlock or panic.
If we want to make a good library that is easy to use, it will be better the library manages these things in its code.
There was a problem hiding this comment.
My intention is make as many options as possible, for full control over the context. I think we can think about this later
No description provided.