Sreekant Sreedharan - 2015-12-11

I had a few suggestions for improvements to the API. I was hoping you would consider it.

  • A C API to complement the C++ API - There are several reasons for this, but the main one is that a library ABI in C++ is not compatible across compilers on any single platform. This is because each C++ compiler has its own dialect for name mangling. This makes it impossible to load the library dynamically using LoadLibrary (Win32) or dlsym (Posix). (Note: If you'd like to do this, just send me a message and I can send you a quick draft on a version I put together).
  • The epoll api requires quiet a bit of refinement. Firstly, the epoll_create function could have additional arguments to allow for options to control the behavior of the epoll handle. Note how the system epoll_create had to evolve into epoll_create1. If you would like to keep the API static, I'd recommend a better option which is to add an epoll_setopt and epoll_getopt similar to setsockopt and getsockopt, that allows finer control over the behavior of epoll.
  • The second improvement is for epoll_mod similar to the system epoll_ctl with EPOLL_CTL_MOD. The current state of the API does not allow a modification of a socket handle in an epoll, without removing it entirely. Furthermore, in the context of an deletion or modificaiton, there is no way to know what the current flag set on a particular handle is without also tracking it on the application side. (This is a limitation with the current system epoll_ctl as well, from what I know).
  • The third improvement is to have a wait() method call that is C friendly without the use of an STL container as an argument. The problem with using an STL container as an argument in a public API is that STL containers may have additional statististics and debugging variables embedded in them depending on whether they are built in debug or release mode (or sometimes even if they are passed across modules - from an applicaiton to a library). This can result in very strange behavior that are very hard to debug. I'd recommend a C friendly structure of pointer array as an argument to the wait call (Again, if you'd like my input on this, and my version, just send me a message).

I hope that helps...But all in all, UDT is a phenomenal piece of technology. Thanks for putting this together.