I think that just like everything else in the world, it has some benefits and some downsides.
For me, the greatest benefit is that it enforces some sort of code modularity/standardization and helps people keep their code organized. Note that i am not asserting that any OO code is inherently better written.
While designing libmodule, i always focused on that, plus being simple that, imo, should always be the primary goal while writing any library.
If anybody asks for support for some other OS, i can think about switching to poll(), even if i find epoll-like interfaces to be much more enjoyable to work with. As stated on project's readme, any patch is welcome.
About licensing, GPL is my usual choice there.
If you think any of these points is crucial, and you'd like some changes, please fill a bug report.
> If anybody asks for support for some other OS, i can think about switching to poll(),
Think, adding macOS support is enough.
Windows support un-needed as Windows OS will die soon and it's soul go to clouds. I'm serious, really! There is HN thread about it.
Indeed, i recently added bsd + osx support in libmodule (https://github.com/FedeDP/libmodule/tree/kqueue_support) even if it is not yet in master.
It builds, but I still need to properly test it; expect it to be merged sometime near this weekend.
Do I understand correctly that there can be only one instance of a module? Why then use string identifiers instead of an enum?
String identifiers are human friendly; moreover i can't see how an enum could fit there, care to explain? Thanks!
Btw you can have same module name in different contexts.
That would be less dynamic, but it's all a game of tradeoffs.
It could be beneficial to also support poll, as it's more portable and should be faster for low fd number. Probably not worth the hassle for a side project though.
BTW: nice clean and simple library. I'm more inclined towards libdill and coroutines, but they are certainly more complicated under the hood.
Yes, that surely would work out pretty well and would be slightly lighter too. But it would lack flexibility and simplicity that are my key points for libmodule.
Thanks for your suggestion and feedback though, they are really appreciated. And thanks for the hint on recv(), how could i miss that!