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,be3d89c2ad66a506 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news2.volia.net!npeer.de.kpn-eurorings.net!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Advice on abort Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1131117934.372137.244900@g44g2000cwa.googlegroups.com> <436f6ad8$0$196$edfadb0f@dread11.news.tele.dk> <1131383393.903975.180350@g47g2000cwa.googlegroups.com> Date: Mon, 7 Nov 2005 19:03:17 +0100 Message-ID: <1rb5pcog6iau7$.180ltiuk2q6cv.dlg@40tude.net> NNTP-Posting-Date: 07 Nov 2005 19:03:14 MET NNTP-Posting-Host: 60a710dc.newsread4.arcor-online.net X-Trace: DXC=D[:ejgIfPPldTjW\KbG]kaMX1BZS;MmC65VWMRhSHTe0VQWRXZ37ga[7ZjTA67ckJ=XUkKRe On 7 Nov 2005 09:09:53 -0800, REH wrote: > Poul-Erik Andreasen wrote: >> REH wrote: >>> What are the best options when a task needs to be terminated, but >>> signaling the task may not be possible? We have tasks that sometimes >>> need to be terminated, but may potentially be blocked on a resource, >>> such as a socket. Currently we use OS-specific calls to terminate the >>> task, but I've never liked that. I've been thinking of using the abort >>> statement, but I don't think that's very graceful either. I also would >>> rather not complicate the code (or force polling behavior) by making >>> the sockets non-blocking. Any advice? >>> >> One poosibillty is too use asyncronius transfer of control. Somthing >> like this. >> >> select >> call.foo_entry -- this i is a guarded entry in a protected >> object or -- another task >> -- her can you have anything yuo may need to clean up after the abort >> then abort >> listen_to_socket this is the function wich may be blocked >> end select >> >> Thee foo_entry basicly dosen't need to do anything. an you have onother >> procedure or entry to open it. >> > I was once advised never to use ATC because it is very slow. Is this > true? It was in reference to GNAT. That is not the main concern. The problem is the state in which aborting would leave the socket and the corresponding port. Note also that what you want to do is not an Ada issue at all. Actually you don't want to abort any Ada task. What you want is to cancel an OS operation blocking some Ada task. This can be done *only* by means of the OS being under consideration. There are little choices: 1. Asynchronous I/O without blocking 2. Synchronous I/O with some cancel operation invoked from outside (like closing socket, or Abort_Selection proposed by Marc Criley) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de