Simplifying plibsys sockets

[akalsi87]

I was looking through the documentation and found that plibsys sockets use an opaque structure and require a malloc call for socket initialization.

I was hoping this could be avoided by providing an alternative definition for the socket which uses a fixed size storage for the fd (which can be a void* on Windows but an int everywhere else) to avoid the use of the memory allocator.

Thoughts?

[saprykin]

What is the purpose to not to call one extra malloc()? I mean, anyway you need to call p_socket_new() in order to initialize internal socket state. Thus I don't see any API simplification. Moreover, on Windows WSACreateEvent() is used when creating a socket, and I'm not sure that it doesn't call any memory allocation routines internally. Also changing behaviour of p_socket_new() to not to return an allocated structure will introduce API inconsistency with other parts of the library. So we need a solid reason to change the behaviour of socket creation.

[akalsi87]

I do understand API compatibility concerns, but the reasoning at my end is more toward considering the cases where connections are short lived and made and destroyed often. By using malloc internally, I'm prevented from even having my own pool.

There should be a p_socket_init(PSocket *) and then p_socket_new can call it after the malloc.

It's unfortunate to take away the options as far as memory management from the client.

Just my 2c.

[saprykin]

Yes, I do get your point. But please consider the following:

• As I've mentioned, on Windows WSACreateEvent is called during the socket creation procedure. For sure it allocates system resources which need to be freed with WSACloseEvent. This already introduces resource allocation (i.e. internal system memory or some data structures). You can't get ride of it.
• If you really want to control memory allocation because you are not satisfied with a system's allocator, you can use p_mem_set_vtable function and override all calls to malloc, free, etc.
• I really doubt that a single malloc call overweights socket allocation itself in the system.
• The only case which comes to my mind when you want to take care about a single malloc call during the socket creation is exactly the same one you have described (lot of short-lived connections). On server side usually you create socket and keep it. On client side you can do the same. But if you create and destroy lot of sockets such that a single malloc becomes a bottleneck of performance, than probably you are doing something wrong. Or you have badly designed interaction between a server and a client. I mean, you should use UDP instead of TCP.
• Also consider such things as socket linger time. Creating vast amount of short-lived connections can affect system performance itself.

I don't see any added value in removing a single malloc call for the procedure which is not intended to be a performance critical (creating a socket). Of course, it is nice to have a tool which can do everything and everywhere, but this makes this tool overcomplicated to use as well.

[akalsi87]

Ok. I understand your point of view. Closing.