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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,77efb4ab26922e3 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad.newshosting.com!newshosting.com!198.186.194.249.MISMATCH!transit3.readnews.com!news-xxxfer.readnews.com!news-out.readnews.com!postnews3.readnews.com!not-for-mail Date: Sat, 27 Sep 2008 19:14:05 -0400 From: "Peter C. Chapin" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Blocking syscalls in Tasks References: <49dd14a0-73b9-44b4-a599-c86da7229c6c@f36g2000hsa.googlegroups.com> <48de7e25$0$26371$4d3efbfe@news.sover.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <48debe3b$0$26375$4d3efbfe@news.sover.net> Organization: SoVerNet (sover.net) NNTP-Posting-Host: 3b00c79a.news.sover.net X-Trace: DXC=_bjZ>NGaY^6fe>HaoCKRX>K6_LM2JZB_3NaXLh<0j<863?@`i3kGa5;?NdCP33^X8>JTWW04Ql9b> X-Complaints-To: abuse@sover.net Xref: g2news1.google.com comp.lang.ada:2113 Date: 2008-09-27T19:14:05-04:00 List-Id: schwering wrote: > My understanding is the same -- or at least I nowhere found something > else. > But I wonder about this, because in my opinion there is a great > difference between tasks = userspace threads and tasks = kernelspace > threads. I think the reason this is probably left implementation defined is so that Ada can be implemented on systems that don't provide kernel threads to the applications. On such systems, the Ada runtime can implement user mode threads and still obey the standard. User mode threads do have some nice properties on their own however... specifically, fast context switching times. Thus even when kernel threads are available an implementation might want to provide some options in this area. > Hence, I think there should at least be some way to > check whether in the given implementation of tasks blocking syscalls > block only the calling task or everything. One imagines it would be documented some place. At least you would like to believe that. Peter