Re: Advice on abort

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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