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=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.42.25.17 with SMTP id y17mr19403982icb.11.1405617011020; Thu, 17 Jul 2014 10:10:11 -0700 (PDT) X-Received: by 10.182.143.4 with SMTP id sa4mr17741obb.38.1405617010884; Thu, 17 Jul 2014 10:10:10 -0700 (PDT) Path: buffer2.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!h18no3174771igc.0!news-out.google.com!bp9ni941igb.0!nntp.google.com!h18no3174766igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 17 Jul 2014 10:10:10 -0700 (PDT) In-Reply-To: <1uas8lp70tji4.1jnnhryhd49tu$.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=73.179.102.101; posting-account=wEPvUgoAAABrLeiz_LRhQ3jeEhyfWVMH NNTP-Posting-Host: 73.179.102.101 References: <50bdb713-7ce1-411b-810b-9bdee1d26b7a@googlegroups.com> <19saet0lg87pr.yqkkaxl011gq.dlg@40tude.net> <8a8353c8-3a8e-4b42-9c94-6d6d095faf1d@googlegroups.com> <1uas8lp70tji4.1jnnhryhd49tu$.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <601d8879-8f06-41b4-ab29-57c2b944cd44@googlegroups.com> Subject: Re: Timeouts in Ada From: NiGHTS Injection-Date: Thu, 17 Jul 2014 17:10:10 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.dca.giganews.com comp.lang.ada:187656 Date: 2014-07-17T10:10:10-07:00 List-Id: On Thursday, July 17, 2014 5:48:56 AM UTC-4, Dmitry A. Kazakov wrote: >=20 > The example is quite unrealistic. If the DB client supported asynchronous >=20 > requests, then it would be very unlikely polling. Any reasonably designed >=20 > client would use some waitable OS object instead, i.e. waiting will be >=20 > non-busy. >=20 I've dealt with many database libraries which provide both blocking and non= -blocking queries. The logic behind this is that the blocking function is b= est used in a dedicated query thread whereas non-blocking is typically used= in a single-threaded model where the main process checks up on the state o= f the query object while it takes care of other things, perhaps updating a = progress bar or some other task. I tend to prefer non-blocking processes like this so I can set my own block= ing priority (for instance usleep(250000)). I feel its more portable and ma= nageable to control the block myself.=20 Thank you for your answers. They have been very insightful.