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-Thread: 103376,be3d89c2ad66a506 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!news.tele.dk!not-for-mail Date: Tue, 08 Nov 2005 15:54:45 +0100 From: Poul-Erik Andreasen User-Agent: Debian Thunderbird 1.0.2 (X11/20050817) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Advice on abort References: <1131117934.372137.244900@g44g2000cwa.googlegroups.com> <436f6ad8$0$196$edfadb0f@dread11.news.tele.dk> <1131383393.903975.180350@g47g2000cwa.googlegroups.com> <1rb5pcog6iau7$.180ltiuk2q6cv.dlg@40tude.net> In-Reply-To: <1rb5pcog6iau7$.180ltiuk2q6cv.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4370bc36$0$180$edfadb0f@dread11.news.tele.dk> Organization: TDC Totalloesninger NNTP-Posting-Host: 80.166.145.174 X-Trace: 1131461686 dread11.news.tele.dk 180 80.166.145.174:23196 X-Complaints-To: abuse@post.tele.dk Xref: g2news1.google.com comp.lang.ada:6284 Date: 2005-11-08T15:54:45+01:00 List-Id: Dmitry A. Kazakov wrote: > 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. I am not that good at sockets, So i vould like to know wich problematic (uncleanable) states wee are taking about. > 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) > This will however require that the sockets or select are made public in some way, wich a dont like. PEA