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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,76da32d8c4934801 X-Google-Attributes: gid103376,public From: Mats Weber Subject: Tasking/blocking system calls (was: Ada --> C Translation) Date: 1998/10/16 Message-ID: <3627A0E3.FD167DAC@elca-matrix.ch>#1/1 X-Deja-AN: 401903704 Content-Transfer-Encoding: 7bit References: <6u6flv$qn7$1@nnrp1.dejanews.com> <6vobnk$vt9$1@jupiter.cs.uml.edu> <702jg1$gst$1@prime.imagin.net> Content-Type: text/plain; charset=us-ascii Organization: ELCA Matrix SA Mime-Version: 1.0 Reply-To: Mats.Weber@elca-matrix.ch Newsgroups: comp.lang.ada Date: 1998-10-16T00:00:00+00:00 List-Id: Samuel Mize wrote: > By golly, he's right. we should pick one way and stick to it. If > somebody needs a different one later, he can make up his own darn > language. You can't pick one way for all purposes. Some systems need tasking that is faster or different from kernel threads, while other systems need tasks to be implemented as kernel threads. See e.g. the GNAT documentation for reasons to choose between tasking runtimes. > Seriously, I/O blocking is only ambiguous for the predefined I/O > packages, which are convenience packages. Ada was originally defined > for embedded systems. If I'm building a real-time simulator, or an > embedded radio system, or a crypto module, I really don't care whether > Text_IO blocks the process or not. I'm never going to use it anyway, > I'm going to be watching I/O ports with machine-specific code. ... which could also block the whole process. The reason why Text_IO blocked the whole process in non-kernel-threads tasking implemenetations does not come from Text_IO itself, but from the underlying machine-specific code used to implement Text_IO. > Also, if I recall correctly, this WAS defined for Ada 83, by > implication at least[1]. In Ada 95 the situation was improved by > making it LESS defined. This lets vendors offer more options, > and makes it cheaper to put Ada on new targets. > [...] > [1] A lower-priority tasks's processing -- even a system call -- > should not block a higher-priority task that becomes ready. Some > implementations failed to get that right, and it wasn't tested by > the validation suite, so some compilers that blocked on I/O got > into the community. Which is why you heard the question at all. OK, it was defined, but that is not something you can reasonably enforce on any system without kernel threads. Implementing this on e.g. SunOS (pre-Solaris), AIX 3.x or VMS 5.x, would either require the OS to be modified, or some very unreasonble implementation of tasking, or making all potentially blocking system calls go through an extra layer.