IO scheduling is a separate problem, though it shares the same fundamental properties. The same goes for network packet scheduling. All of these are ongoing efforts. Stay tuned! :)
A simple hierarchy: when there is deadline work to do that work takes precedence, fair work gets the rest of the time. This is effective because deadline work has bounded execution time, whereas fair work is elastic and…
No, that's based on the deprecated multi-level round-robin scheduler, which we find tremendously amusing. :)
It does imply that. Multiple concurrent scheduling algorithms is nothing new, Linux and MacOS both support per-thread algorithm selection.
The library is transport agnostic. There is a Reader/Writer abstraction to adapt to any transport you like. https://github.com/google/libnop/blob/master/docs/getting-st...
In most cases the context provides enough information: void Baz(Bar*); void Baz(const Bar&); void Foo(Bar* mutable_bar) { Baz(*mutable_bar); // Not mutated. } void Foo(Bar* mutable_bar) { Baz(mutable_bar); // Possibly…
For the most part the optimization works well. The more subtle issue is that the union trick used by the endian utilities is not compatible with constexpr expressions. There are some interesting use cases for constexpr…
The table approach is fairly flexible. Both Protos and FlatBuffers do more or less functionally similar things. What specific deficiency do you see? Take a look at the binary format spec:…
Supporting embedded platforms is one of the objectives of the library. Feel free to open a ticket on github if you have any further questions.
Thanks! MessagePack is one of the influences.
I tried to keep it C++11, but generalized lambdas are critical in important use cases (see nop::Variant). Besides, GCC and Clang have solid C++14 support. C++17 is another story... ;-)
Since you mention it, check out the experimental RPC support: https://github.com/google/libnop/blob/master/examples/interf... https://github.com/google/libnop/blob/master/include/nop/rpc... I haven't documented it yet…
This argument comes up a lot within Google. The style guide is revisited frequently (for example =delete in the public section is now the standard for disabling copy and/or move/assignment vs. the old macros in the…
unique_ptr and nop::Optional<unique_ptr<T>> is on the way. shared_ptr opens up the ability to create cycles, which are not supported yet.
It means not currently an officially supported project. Most open source releases of internal code start out this way and may or may not become officially supported. It is different than deprecated, which was once…
Primary author and maintainer here! Happy to answer any questions anyone has.
IO scheduling is a separate problem, though it shares the same fundamental properties. The same goes for network packet scheduling. All of these are ongoing efforts. Stay tuned! :)
A simple hierarchy: when there is deadline work to do that work takes precedence, fair work gets the rest of the time. This is effective because deadline work has bounded execution time, whereas fair work is elastic and…
No, that's based on the deprecated multi-level round-robin scheduler, which we find tremendously amusing. :)
It does imply that. Multiple concurrent scheduling algorithms is nothing new, Linux and MacOS both support per-thread algorithm selection.
The library is transport agnostic. There is a Reader/Writer abstraction to adapt to any transport you like. https://github.com/google/libnop/blob/master/docs/getting-st...
In most cases the context provides enough information: void Baz(Bar*); void Baz(const Bar&); void Foo(Bar* mutable_bar) { Baz(*mutable_bar); // Not mutated. } void Foo(Bar* mutable_bar) { Baz(mutable_bar); // Possibly…
For the most part the optimization works well. The more subtle issue is that the union trick used by the endian utilities is not compatible with constexpr expressions. There are some interesting use cases for constexpr…
The table approach is fairly flexible. Both Protos and FlatBuffers do more or less functionally similar things. What specific deficiency do you see? Take a look at the binary format spec:…
Supporting embedded platforms is one of the objectives of the library. Feel free to open a ticket on github if you have any further questions.
Thanks! MessagePack is one of the influences.
I tried to keep it C++11, but generalized lambdas are critical in important use cases (see nop::Variant). Besides, GCC and Clang have solid C++14 support. C++17 is another story... ;-)
Since you mention it, check out the experimental RPC support: https://github.com/google/libnop/blob/master/examples/interf... https://github.com/google/libnop/blob/master/include/nop/rpc... I haven't documented it yet…
This argument comes up a lot within Google. The style guide is revisited frequently (for example =delete in the public section is now the standard for disabling copy and/or move/assignment vs. the old macros in the…
unique_ptr and nop::Optional<unique_ptr<T>> is on the way. shared_ptr opens up the ability to create cycles, which are not supported yet.
It means not currently an officially supported project. Most open source releases of internal code start out this way and may or may not become officially supported. It is different than deprecated, which was once…
Primary author and maintainer here! Happy to answer any questions anyone has.