We don't need parent or child ids unless debugging. IDLE and EXPIRED
conn logs do not need to report ids either. Ids are useful only in
detailed debug logs.
This is necessary to uniquely identify child conns. The src fd of child
conns was possibly not unique. We use this id in debug logs only.
Also relocate the update code related with this id.
Do not pass pxy_thr_print_children() or bufferevent_getfd() to MAX() or
util_max() macro functions as params, or else they are called twice.
Since MAX() macro call duplicates params, do not call it nested either,
or else we get very long macro expansions.
We have carried almost all conn init tasks from thrmgr to conn handling
thread. So we immediately add the conn to the conn list of its thr,
which renders both pending ssl conns list and in_thr_conns flag useless.
The only time we go over the linked list is to check idle or expired
connections, or to print debug info. Otherwise, mostly what we need is
to add and remove list nodes. Removing a list node becomes a very simple
task if we keep track of the previous node too. So now we also keep
record of prev node, and update prev node as we add and remove nodes.
All three linked lists we use benefit from this data structure
improvement, making it very fast to remove a list node.
Another benefit of this change is that we don't need to identify conns
with their id numbers or child conns with their src fds. So now we
directly delete them, without needing to check their ids or fds.
Do we need a thr mutex? This mutex is for thread-safe access to
thr.load. But thrmgr read-accesses thr.load, and write-accesses are by
thr only. So can we really live without it?
Soner Tari