another thread to the mainthread in a safe manner.
This is used for the DNS lookup code, and can also
be used by the signal handler to safely report actions back
to the application mainloop without using global variables.
This happened due to the network polling mechanism had nothing to poll
for, so it returned immediately only to be called again (during DNS lookup).
This fix introduces a control pipe that is polled for reading, althoug nothing
is ever sent to that pipe. But, it can be used instead of the signal
handler approach which is currently used for terminating the program.
The downstream connection callback must only be invoked when the event
that SSL requests for the connection to make progress has actually
occured. Otherwise, the downstream callback might do nothing but
re-queue an unrelated event (e.g. in user_net_io_want_write), and the
event loop comes around instantly while making no progress. Track the
SSL-requested events separately and deliver the required downstream
event when they fire.
Sample strace:
epoll_wait(0, {{EPOLLIN, {u32=96, u64=96}}}, 91, 10000) = 1
: net_ssl_callback in state tls_st_need_write calls cb NET_EVENT_WRITE
: User writes data, OpenSSL tries to write data
write(96, <snip>..., 170) = -1 EAGAIN (Resource temporarily unavailable)
: handle_openssl_error requests NET_EVENT_WRITE
epoll_ctl(0, EPOLL_CTL_MOD, 96, {EPOLLOUT, {u32=96, u64=96}}) = 0
: User callback then requests NET_EVENT_READ|NET_EVENT_WRITE
epoll_ctl(0, EPOLL_CTL_MOD, 96, {EPOLLIN|EPOLLOUT, {u32=96, u64=96}}) =
: Data available for *reading*
epoll_wait(0, {{EPOLLIN, {u32=96, u64=96}}}, 91, 10000) = 1
: net_ssl_callback in state tls_st_need_write calls cb NET_EVENT_WRITE
: again...
the given amount of messages in the configured interval.
The previous behavior allowed n+2 messages in the interval, due to
two off by one comparison rules.
In addition, if flooding is detected then each new message after the flooding
is detected will reset the interval timer, which means the client
cannot send another message until the timeout interval expires.
This could essentially happen due to time drift,
high load, or the process being put in sleep for a while.
The reason is that recurring timers could be added to the same time slot
as the timeslot being handled.
