
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi,<div><br></div><div>When a gen_server (or gen_fsm, which is very similar in this aspect) is waiting for a message with a finite timeout but receives a system message, it will return to the message loop with the original timeout value. I think this is an incorrect behaviour.</div><div><br></div><div>Let’s say I set the timeout to 60 seconds, and 20 seconds later a system message arrives. After handling it the gen_server loop will wait a full 60 seconds until I receive the timeout - a total of 80 seconds instead of 60. Even worse, if a monitoring tool (like observer) keeps polling the server for its state I may never ever get a timeout.</div><div><br></div><div><div>The docs say:</div><div><br></div><div><blockquote type="cite"><span style="font-family: Verdana, Arial, Helvetica, sans-serif; background-color: rgb(255, 255, 255);">If an integer timeout value is provided, a timeout will occur unless a request or a message is received within </span><span class="code" style="font-family: Courier, monospace; background-color: rgb(255, 255, 255);">Timeout</span><span style="font-family: Verdana, Arial, Helvetica, sans-serif; background-color: rgb(255, 255, 255);"> milliseconds.</span></blockquote></div></div><div><br></div><div>I’m not sure whether a “message" in this text should mean a "system message" too, but I think system messages are not very well known and for me the docs read my gen_server code will get back the control via a handle_call, handle_cast or handle_info callback within the timeout specified. Loosing control for ever is definitely not something I would be prepared for when setting a timeout.</div><div><br></div><div>So I believe the gen_server code shall record the time when the wait started, and after processing a system message deduce the elapsed time from the original timeout. This way the timeout would occur when it should (unless the process receives system messages faster than it could handle them and can never clear its message queue of course).</div><div><br></div><div>Let me know whether you agree with me on the expected behaviour - if you do, I can write a patch and submit a PR, but I don’t want to waste my time working on a non-issue.</div><div><br></div><div>Thanks & Regards,</div><div>Daniel</div></body></html>