Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Hi.
In the case of the Timeout resolution the value is re-examined at the end of a notional timeout-check cycle. One might think of these checks as going on independently of any calls you make, e.g. in a different thread. In reality the first cycle will start the first time you make an xroot call, and continue going on for some time (many minutes) after your last xroot call. (Or until the program finishes).
So in the example in your comment above, the first time-check cycle of 15s is started at the time of the first fs.ping. A timeout happens within the cycle, so at the end of the 15s a timeout is reported back as an error in the status code. A second cycle of 15s in immediately started, as there's hasn't been quite enough time for python to execute the "EnvPutInt" to change the value. A second timeout happens at the end of that cycle, and then the third cycle of 5s starts. The timeout value in the 3rd ping is 10s and it is apparently detected at the end of a 2nd 5s cycle. It could be that sometimes that is reported after about ~10s, as in the result above, or perhaps after 3 x 5s cycles = ~15s as the specified ping timeout value is very close to a multiple of the cycle-length and the ping starts about the same time as a cycle.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1