It's no secret that I dislike C. That said, I'm very pleased to see libraries like this, because I think that much of what are extolled as the benefits of OOP can be achieved with effective use of message-passing between modules. This handles both stateless and stateful components well, in many cases better than C++/Java-style class-oriented OOP.
There are some developers who think that OOP is a bless; other developers think that OOP is a sh*t and try to stay away from it as much as possible.
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.
Yes, that's it. Indeed i'm really open to support other platforms; i used linux-only epoll because of its beautiful API and only support linux because i can only test on it.
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.
I cannot say much about AzPainter, sorry.
Libmodule is designed to be flexible enough in managing events, so if you are writing any event driven software and that event exposes a file descriptor, you should be able to use libmodule without any issue.
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.
You are probably right about recv; i'll change it to "receive" as soon as i get home (patch welcome though).
There can only be one instance, you're right.
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.
I guess it would change the API. You could have a separate file where you define an enum with all module identifiers plus a max value that all modules should include. Then you could omit whole hashmap dance and just use a static array. Then even an IDE or your text editor could give completions easily.
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.
Oh i see, that is what i firstly thought reading your comment.
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!
