Originally posted by [b]theultramage[/b]
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=394
During my experiments with some WiP code and socket stall time lowered to 10 seconds, sometimes the connections suddenly timed out, even though I coded a keepalive that was explicitly sent 2 seconds before the connection would expire. This always took at most 1 minute to happen.
Since the timeout is dependent on a session's rdata_tick, I added a debug message that would print it, along with the current system time.
Immediately I noticed that something wasn't right. The increments of system time didn't match the increments of last_tick! Sometimes they would match, sometimes they'd be off a second or two.
A quick check revealed the culprit. In pseudocode,
CODE
func do_sockets()
{
last_tick = time(); // get current time
select(timeout); // wait a while, until something arrives or a timer should execute
process(last_tick); // do stuff that's based on last_tick
}
So the code executes on a value that can fluctuate wildly depending on the amount of timers active. The bad case happens when the delayed value gets saved as rdata_tick, and then in the next iteration, last_tick jumps forward by a value higher than the number of seconds elapsed since last iteration. Boom.
Not sure what to do about this... moving the last tick update call didn't seem to help...
QUOTE
[01:56:59][Debug]: tick is 1194569819
[01:57:01][Debug]: tick is 1194569819
[01:57:07][Debug]: tick is 1194569827
[01:57:09][Debug]: tick is 1194569827
[01:57:11][Warning]: Connection to login-server lost (connection #308).