GSocket control messages API is not ideal
Submitted by Sebastian Dröge @sdroege
Link to original bug (#769994)
Description
Currently control messages are implemented as full GObjects and are globally registered. This has a couple of problems:
- there could be multiple implementations for the same control message if you e.g. use two libraries that want to use the same one and implement them locally
- the boilerplate code required to add support for a control message is immense
- you require yet another quite expensive allocation per UDP packet, which can become a real problem if you have a few 10k packets per second
It would seem like a more flexible approach that would also cover the above, to register per socket (or even per receive/send) the interest in specific control messages together with functions to serialize/parse them, and have them passed as simple C struct pointers to the API.
That way one could e.g. also implement support for a specific control message by just having the content of it memcpy'd into stack allocated memory during receiving.
This should be possible to implement in GSocket, etc in a backwards compatible way even at this point and allows to deprecate the existing API. It would have to come with new g_socket_receive/send_messages() variants with new names though.
Any opinions? Other ideas how this can be implemented in a better way to solve the above problems?