Well the problem i am (feeling) im facing is the way its handled while
closing the socket.
I have 1..n threads that handles socket events for 60 sockets, every time i
get an event on a socket its handled in a function (all the FD_XXXX's
This function will stuff an outgoing queue with complete incoming
datapackets recieved, this is a sempahore based queue, that is popped from
another thread where its handled.
In this other thread i also control when i am about to send some data to a
socket (and in the end close it) or when i am about to connect to a
serverside socket and then i can tell the threadpool to incooperate this
socket in its list of sockets.
This is working very fine, but when im gonna close a socket manually, then
its get abit messy.
I send data, and then i make a shutdown on the socket (FD_READ) so that
socket will receive the FD_CLOSE notification when everything is sent.
But since the FD_CLOSE is happening in another thread, and i dont have a
direct link between the place where im shutting it down (my other thread),
and where it actually shuts down, i sometimes come in a condition, where
theres already new data to be sent to the actual socket-connection (or more
precise, on the given IP, since every connection is based on IP from a
So somehow i would really like to halt everything until im sure the socket
is closed ?
A solution in this architecture could be is to have a flag in my
socket-objects that indicate that the socket is "closing" and in the end
"closed" ? and then discard any attempts to access this socket while
"closing" until its actually "closed" ?
Anyways, the idea of using pure blocking sockets, and have a one thread pr.
socket, that handles the events, BUT also handles every action performed on
this socket with a queue for outgoing packets would ensure me that i only
access a socket one place in all the code - and my idea was to have a simple
commandbased queue-protocol, so i would have a "send" a "close" and a
"connect" part (read would be handled automatically) - so when i wanted to
send something and close it i would do this:
result = ThisSocket->Push (sendpacket)
result = ThisSocket->Push (closepacket)
As soon as the thread receives the "closepacket" it would block the queue
for any more incoming packets, so i would know in my code that when the push
returns "result = fail" that the specific socket isnt ready, when the thread
is sure that the socket is closed, then it would unblock the queue so its
ready to receive data again.
Ofcourse, if i could implement such a feature in the architecture i have
today with multiple socketevents pr. thread, that would be the most optimal
case, but here i dont control a semaphorebased queue pr. socket, here i
work directly at the objects.
While writing i got some ideas though lol.....but any reflection about my
writings here are appriciated :) but the idea that just popped up, was to
implement the "block-queue" on my socket objects "to be sent"
buffer.....when in "closing" state, it should discard any sends.........