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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c2dda499a002ec3c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-11 09:02:45 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!cyclone.socal.rr.com!cyclone3.kc.rr.com!news3.kc.rr.com!twister.socal.rr.com.POSTED!not-for-mail Message-ID: <3CB5B3B1.9442DA54@san.rr.com> From: Darren New X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: rendez-vous underlying mechanism References: <3CA2A827.11140295@adaworks.com> <7vr8lmiha5.fsf@vlinux.voxelvision.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 11 Apr 2002 16:01:51 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: twister.socal.rr.com 1018540911 66.75.151.160 (Thu, 11 Apr 2002 09:01:51 PDT) NNTP-Posting-Date: Thu, 11 Apr 2002 09:01:51 PDT Organization: RoadRunner - West Xref: archiver1.google.com comp.lang.ada:22365 Date: 2002-04-11T16:01:51+00:00 List-Id: Ole-Hjalmar Kristensen wrote: > Agreed, but it would be reasonable to see a language standard specify > that blocking a task would not block the entire program. It's a pity > it's not covered in the Ada standard. I think you'd get into all kinds of things about what "blocking a task" means. For example, for a while I worked on one system where requesting to allocate memory when there wasn't any swap space left got you swapped out until some other program freed up memory. There's no way to not block all the tasks if your process isn't in core. And it's just a memory allocation doing this, not even any user-visible I/O. If a task calls "suspend my processes until the operator mounts the tape", it's hard to guess whether you want the other threads running or not. In UNIX-land it can be pretty easy to guess. Making such guesses portable could be problematic. Providing a list of what OS calls will block all threads is probably about as close as you can come, but that wouldn't have solved the original problem, since the I/O that blocked your code would have just been on that list. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. Remember, drive defensively if you drink.