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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,534dd301375921ac X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.219.170 with SMTP id pp10mr8979449pbc.1.1339834485287; Sat, 16 Jun 2012 01:14:45 -0700 (PDT) Path: l9ni56600pbj.0!nntp.google.com!news1.google.com!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Is Text_IO.Put_Line() thread-safe? Date: Sat, 16 Jun 2012 10:14:33 +0200 Organization: cbb software GmbH Message-ID: <15ejiqzwmm28q.1pq77vn14l7h3.dlg@40tude.net> References: <93201f1a-d668-485e-83b4-492bc283f36e@googlegroups.com> <3fff1269-06f5-47a2-bc10-c2145b3a297d@googlegroups.com> <17b8mcqy4f63k$.1jwvmc6qjjvnq$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 4RFYTQ6jM/dAKFJoI0fUkg.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: 2012-06-16T10:14:33+02:00 List-Id: On Sat, 16 Jun 2012 09:03:08 +0100, Simon Wright wrote: > "Dmitry A. Kazakov" writes: > >> On Sat, 16 Jun 2012 07:49:26 +0100, Simon Wright wrote: >> >>> "J-P. Rosen" writes: >>> >>>> Le 16/06/2012 04:00, BrianG a �crit : >>>>> On the Put_Line issue, why not simply wrap it in a protected object >>>> Because all IO's are potentially blocking operations. >>>> >>>> By all means, use a task and a rendezvous! Simple, no problem, it >>>> works. PO are for simple, relatively low level stuff (in >>>> general). Rendezvous are generally better for high level >>>> synchronization. >>> >>> I feel more comfortable it the output requests are queued, so a PO >>> wrapping a queue with an outputter task seems natural. >> >> That would need marshaling. Rendezvous and mutexes are great because >> they copy nothing. > > So? this is usually for debug. When debugging you should not pump the stack and heap too much. You also would not like to keep it in the volatile memory for too long, because the thing might crash before that reaches the hard drive or monitor. >> IMO, queues should only be used for asynchronous scenarios. > > In my scenario, getting the log information out is lower-priority than > handling the real-time processing. You May Not Block while processing > events. Yes, RT is one case where one wanted to convert a synchronous operation into an asynchronous one. But that is a design decision motivated by more than mere task-safety reasons. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de