coreytabaka

7 ms·

1.
by coreytabaka 7y ago
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! :)
2.
by coreytabaka 7y ago
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 can adjust to use th
3.
by coreytabaka 7y ago
No, that's based on the deprecated multi-level round-robin scheduler, which we find tremendously amusing. :)
4.
by coreytabaka 7y ago
It does imply that. Multiple concurrent scheduling algorithms is nothing new, Linux and MacOS both support per-thread algorithm selection.
5.
by coreytabaka 8y ago
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...
6.
by coreytabaka 8y ago
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)
7.
by coreytabaka 8y ago
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 serialization that fa
8.
by coreytabaka 8y ago
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: https://github.com/google/libno
9.
by coreytabaka 8y ago
Yes! Hopefully C++20 or C++25-ish will provide better alternatives for compile-time reflection. Don't forget that libnop also has NOP_EXTERNAL_STRUCTURE (and friends) to decouple the annotation from the structure definition. This is ha
10.
by coreytabaka 8y ago
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.
11.
by coreytabaka 8y ago
Thanks! MessagePack is one of the influences.
12.
by coreytabaka 8y ago
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... ;-)
13.
by coreytabaka 8y ago
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/mas
14.
by coreytabaka 8y ago
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 private section
15.
by coreytabaka 8y ago
Thanks for considering using libnop! This library works well in an embedded context. I've personally used it on Cortex-M class micro controller firmware. The serializer/deserializer does not require dynamic memory allocation. Whet
16.
by coreytabaka 8y ago
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.
17.
by coreytabaka 8y ago
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 supported but no longer.
18.
by coreytabaka 8y ago
Primary author and maintainer here! Happy to answer any questions anyone has.