From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8da181ade72859cf X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: timeouts References: From: Brian May Date: Sun, 29 Aug 2004 10:24:27 +1000 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:aUaS06YRIka3E7W8uTE9fqz1KSs= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: dsl-202-173-153-89.vic.westnet.com.au X-Trace: news.melbourne.pipenetworks.com 1093739067 202.173.153.89 (29 Aug 2004 10:24:27 +1000) X-Complaints-To: abuse@pipenetworks.com X-Abuse-Info: Please forward all headers to enable your complaint to be properly processed. Path: g2news1.google.com!news2.google.com!news.maxwell.syr.edu!news.mel.connect.com.au!news.netspace.net.au!news.melbourne.pipenetworks.com!not-for-mail Xref: g2news1.google.com comp.lang.ada:3125 Date: 2004-08-29T10:24:27+10:00 List-Id: >>>>> "Stephen" == Stephen Leake writes: Stephen> I had a similar problem, and tracked it down to a "pragma Stephen> Debug" in the GNAT sources for Ada.Text_IO. Try compiling Stephen> without -gnata. Mine went away with the next release of Stephen> GNAT (5.02a1). Hmmm... Interesting... That is probably my problem. Yes, I am compiling with -gnata, too. When it annoys me enough I will try removing the -gnata. So far, I haven't reached this threshold. Anyway, to followup on my original problem: With gnat 3.15p, after approx 12 hours, my timeouts stopped working and/or took excessively long (e.g. in the order of hours instead of 0.1 of a second). With mingw32 3.4.1, candidate release, after 12 hours, timeouts were still working. Unfortunately, instead of 0.1 seconds, each one was 4.6 seconds. This is on a XP computer with no other applications running[1]. While this is OK for my application, I am concerned that there is still something wrong... If I restart the application, it comes good. I have another theory, it could be a problem with my logging code (weird theory, I know) that prints the date & time. In order to rule this out, I am now using Ada.Text_IO.Put_Line directly without printing the date and time immediately before the select statement, and at the start of each event, and this should enable to be prove that the delay really is in the select statement. Note: [1] Interestingly, task manager reported 50% CPU used by the msys terminal. After I restarted the process the CPU usage dropped to less then 1%. To me, this makes absolutely no sense, as surely more CPU would be required to update the screen when it is getting updated several times a second, not when there was a 4.6 second delay? -- Brian May