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,77efb4ab26922e3 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!cyclone1.gnilink.net!gnilink.net!wn11feed!worldnet.att.net!bgtnsc04-news.ops.worldnet.att.net.POSTED!53ab2750!not-for-mail Newsgroups: comp.lang.ada From: anon@anon.org (anon) Subject: Re: Blocking syscalls in Tasks Reply-To: no to spamers (No@email.given.org) References: <49dd14a0-73b9-44b4-a599-c86da7229c6c@f36g2000hsa.googlegroups.com> X-Newsreader: IBM NewsReader/2 2.0 Message-ID: Date: Sun, 28 Sep 2008 03:16:28 GMT NNTP-Posting-Host: 12.65.150.239 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1222571788 12.65.150.239 (Sun, 28 Sep 2008 03:16:28 GMT) NNTP-Posting-Date: Sun, 28 Sep 2008 03:16:28 GMT Organization: AT&T Worldnet Xref: g2news1.google.com comp.lang.ada:2114 Date: 2008-09-28T03:16:28+00:00 List-Id: Except for DOS in todays OS all Ada partitions are executed by native OS threads. Only the calling Ada task aka thread is blocked, unless other tasks require access to that blocked task, then they become blocked as well. Also, this is stated indirectly in a number of sections and annexes in the "Ada RM". Plus, this goes beyond Ada, it is the norm for all multi-tasking language and environments. In GNAT Ada tasking environment where one or more task are beginning executed the Binder has elaborate the main procedure so the main procedure on exit will be blocked until all sub task have terminated. Then once unblocked the main procedure will call "Ada.Finalization.Finalize" and exit to system. Calling any blockable system routine will block the Ada task aka thread if needed until conditions have been meet. A call to Ada.Text_IO.Get to obtain data from the keyboard will block the calling task until data is ready for the Ada.Text_IO.GET routine and all other tasks may be unblocked, depending on their needs. In GNAT.Sockets, most system calls like a tcp/ip "accept" or tcp/ip "read" function will block the thread or task "Forever" until a connection or data is ready for the tcp/ip "read" function. Some other routines have a timeout parameter which can be used to unblock the call and task at a set time interval. Now, in a GUI system, the RC_TASK (resource task) is blocked until a input device such as the mouse or keyboard actives the thread. But the other tasks within the partition may be unblocked unless they need protected information from the RC thread. In <49dd14a0-73b9-44b4-a599-c86da7229c6c@f36g2000hsa.googlegroups.com>, schwering@gmail.com writes: >Hi there, > >I'm wondering whether a blocking system call like read() called via C >interfacing in a task would block only the task or the complete >process. > >Are tasks commonly implemented using threads and does the language >specification request tasks to be in the user- or kernelspace? Or is >there a real difference between tasks and threads? > >Greetings and thanks in advance > >Chris