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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,63360011f8addace X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-07-18 06:38:08 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed.news.nacamar.de!news-x2.support.nl!psinet-eu-nl!psiuk-p4!uknet!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: gnat: time-slicing Date: Wed, 17 Jul 2002 15:57:56 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <5ee5b646.0207161329.5c8e387b@posting.google.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1026935877 23808 136.170.200.133 (17 Jul 2002 19:57:57 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 17 Jul 2002 19:57:57 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:27222 Date: 2002-07-17T19:57:57+00:00 List-Id: Terminology problems here. You are thinking of a "file" as a file-system file that resides on a disk with permanence, etc. Ada thinks of a "file" as sort of a logical thing - the ultimate destination of the data being something beyond the scope of the language. (Could be a terminal or disk file or paper-tape or network pipe or whatever...) So to Ada the console is a file. (Not surprisingly, Unix kind of likes to think of all its device drivers as files, so it isn't as if Ada invented something new.) So from a logical perspective, the "file" (in the sense of an Ada.Text_IO.File_Type object) is a "variable" ("object" in Ada parlance) and if you are accessing the same variable from two tasks (which you do implicitly with Put_Line, since the default is to use an object denoted by the function Current_Output) this could be A Bad Thing. Accessing a shared variable from two threads of control is going to result in unpredictable behavior unless you do something to explicitly control the access. If you hide the Put_Line subprogram behind your own Put_Line subprogram that exists inside a protected object, you can guarantee that the tasks have to get in line and wait their turn to access the shared output file. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Jan Prazak" wrote in message news:pan.2002.07.17.21.38.14.849546.1934@gmx.net... > > If it's true, then the Linux console/terminal is a file. Duhuhuh. :) > No, seriously, explain it a bit more. As far as I know, a terminal is a > device in Linux, which is some kind of a file, maybe you mean this. When > I run the program in konsole (KDE xterm), the output is on the screen, > and that's logical, because I haven't specified a file in Put_Line. >