Advice on abort

Advice on abort

[REH]

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?

Re: Advice on abort

[Marc A. Criley]

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?

For the _specific_ case of blocking on a socket...

IF you're using GNAT, and
IF you're using GNAT.Sockets,

then take a look at the Selector functionality.  (This is an abstraction 
over the C select() function.)

Basically, once you get your socket and set up your selector you wait 
for traffic with a Check_Selector(...) call.  When you're ready to shut 
down, you can call Abort_Selector(...).  CheckSelector() then returns 
with a status of Aborted, and you can then go on about your termination.

I changed over to this in the version of DTraq that's getting updated 
and the code is now _much_ cleaner in this area.

(I don't know when Check_Selector and Abort_Selector were added to 
GNAT.Sockets, coulda been years ago.  I just happened to stumble across 
them when scanning through the spec a few months ago :-)

-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: Advice on abort

[Dmitry A. Kazakov]

On 4 Nov 2005 07:25:34 -0800, 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?

Close that socket from another task. That should end the blocking I/O on
the socket with some error code. And the task will become ready accept a
rendezvous. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Advice on abort

[REH]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:l1ius2k66aqm.1n607d42c495j.dlg@40tude.net...
> On 4 Nov 2005 07:25:34 -0800, 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?
>
> Close that socket from another task. That should end the blocking I/O on
> the socket with some error code. And the task will become ready accept a
> rendezvous.
>
Thank you!  You know, the simple solution always eludes me.

REH

Re: Advice on abort

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Close that socket from another task. That should end the blocking
> I/O on the socket with some error code. And the task will become
> ready accept a rendezvous.

We have recently been bitten by OS-dependent behaviour in this area.

On Windows, the read fails immediately with an
GNAT.Sockets.Socket_Error exception. However, on VxWorks and Linux
(and possibly other OS's), you get a successful read of *zero* bytes
(at any rate, fewer than you requested) and the exception only happens
on the next read.

Of course, getting a short read may end up with an
Ada.IO_Exceptions.End_Error anyway (we had forgotten to check the
length :-( ).

Re: Advice on abort

[REH]

"Simon Wright" <simon@pushface.org> wrote in message 
news:m2fyqb9c6o.fsf@grendel.local...
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> Close that socket from another task. That should end the blocking
>> I/O on the socket with some error code. And the task will become
>> ready accept a rendezvous.
>
> We have recently been bitten by OS-dependent behaviour in this area.
>
> On Windows, the read fails immediately with an
> GNAT.Sockets.Socket_Error exception. However, on VxWorks and Linux
> (and possibly other OS's), you get a successful read of *zero* bytes
> (at any rate, fewer than you requested) and the exception only happens
> on the next read.
>
> Of course, getting a short read may end up with an
> Ada.IO_Exceptions.End_Error anyway (we had forgotten to check the
> length :-( ).

That's fine.  We are VxWorks too.  Besides, a return of 0 on a read is not 
considered "successful" with sockets.  It means the socket has been closed. 
You got an exception on the next read, because you were trying to read from 
a closed socket.

REH

Re: Advice on abort

[Simon Wright]

"REH" <me@you.com> writes:

> That's fine.  We are VxWorks too.  Besides, a return of 0 on a read
> is not considered "successful" with sockets.  It means the socket
> has been closed.  You got an exception on the next read, because you
> were trying to read from a closed socket.

Yes -- but the bug didn't show on Windows because of the different OS
behaviour.

Re: Advice on abort

[REH]

"Simon Wright" <simon@pushface.org> wrote in message 
news:m2br0y9g9w.fsf@grendel.local...
> "REH" <me@you.com> writes:
>
>> That's fine.  We are VxWorks too.  Besides, a return of 0 on a read
>> is not considered "successful" with sockets.  It means the socket
>> has been closed.  You got an exception on the next read, because you
>> were trying to read from a closed socket.
>
> Yes -- but the bug didn't show on Windows because of the different OS
> behaviour.

I don't understand.  What bug?  A return of 0 is not a bug.  I don't think 
you've encountered different OS behavior.  winsock will also return 0 from 
read when a socket closes.  If I understand you correctly, you've 
encountered a particular behavior with GNAT on Windows, not Windows itself. 
Or I may have completely misunderstood what you were saying.

Re: Advice on abort

[Simon Wright]

"REH" <me@you.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:m2br0y9g9w.fsf@grendel.local...
>> "REH" <me@you.com> writes:
>>
>>> That's fine.  We are VxWorks too.  Besides, a return of 0 on a read
>>> is not considered "successful" with sockets.  It means the socket
>>> has been closed.  You got an exception on the next read, because you
>>> were trying to read from a closed socket.
>>
>> Yes -- but the bug didn't show on Windows because of the different OS
>> behaviour.
>
> I don't understand.  What bug?  A return of 0 is not a bug.  I don't think 
> you've encountered different OS behavior.  winsock will also return 0 from 
> read when a socket closes.  If I understand you correctly, you've 
> encountered a particular behavior with GNAT on Windows, not Windows itself. 
> Or I may have completely misunderstood what you were saying.

The bug in our software where we didn't check the length returned.

Mind, I too think that we should have seen a return of 0 under
Windows, and I am completely convinced (but the evidence isn't on this
machine) that we didn't. We should see an End_Error from String'Input
but instead we se a Socket_Error with 'connection reset by peer'.

You could be right that it's a GNAT thing, but the GNAT code looks
identical in this area.

Re: Advice on abort

[REH]

"Simon Wright" <simon@pushface.org> wrote in message 
news:m27jbla69k.fsf@grendel.local...
> "REH" <me@you.com> writes:
>
>> "Simon Wright" <simon@pushface.org> wrote in message
>> news:m2br0y9g9w.fsf@grendel.local...
>>> "REH" <me@you.com> writes:
>>>
>>>> That's fine.  We are VxWorks too.  Besides, a return of 0 on a read
>>>> is not considered "successful" with sockets.  It means the socket
>>>> has been closed.  You got an exception on the next read, because you
>>>> were trying to read from a closed socket.
>>>
>>> Yes -- but the bug didn't show on Windows because of the different OS
>>> behaviour.
>>
>> I don't understand.  What bug?  A return of 0 is not a bug.  I don't 
>> think
>> you've encountered different OS behavior.  winsock will also return 0 
>> from
>> read when a socket closes.  If I understand you correctly, you've
>> encountered a particular behavior with GNAT on Windows, not Windows 
>> itself.
>> Or I may have completely misunderstood what you were saying.
>
> The bug in our software where we didn't check the length returned.
>
Ah, I see.  I did misunderstand you.  Sorry.

Re: Advice on abort

[Poul-Erik Andreasen]

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.


PEA.

Re: Advice on abort

[REH]

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.
>
>
> PEA.

I was once advised never to use ATC because it is very slow.  Is this
true?  It was in reference to GNAT.

Re: Advice on abort

[Dmitry A. Kazakov]

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

Re: Advice on abort

[Poul-Erik Andreasen]

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

Re: Advice on abort

[Dmitry A. Kazakov]

On Tue, 08 Nov 2005 15:54:45 +0100, Poul-Erik Andreasen wrote:

> 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.

It all depends on the particular implementation of the socket library and
how Ada tasks are mapped to system threads and processes. All sorts of
resource leaks are thinkable. For example, you might be unable to listen
that TCP/IP port until process restart or it won't abort etc.

>> 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.

Not necessarily. It seems natural to decouple A) the higher level protocol
[encapsulates a task] from B) the communication object [likely passive,
encapsulates socket, COM port etc].

   type B is abstract new Root_Stream_Type with ... -- Abortable streams
   procedure Abort is abstract;

   type Socket_Stream is new B with private ...;
   type COM_Stream is new B with private ...;

   type A (Stream : access B'Class) is ...;
   procedure Abort (X : in out A);
private
   type A ... record
      Reader : Some_Task_Ptr;
   end record;

procedure Abort (X : in out A) is
begin
   Abort (X.Stream); -- Aborts I/O
   Free (Reader); -- Terminates the task
end Abort;

With Ada 2005 interfaces one could even avoid mix-ins.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Advice on abort

[Marc A. Criley]

Dmitry A. Kazakov wrote:
> On Tue, 08 Nov 2005 15:54:45 +0100, Poul-Erik Andreasen wrote:
 >
>>I am not that good at sockets, So i vould like to know  wich problematic 
>>(uncleanable) states wee are taking about.
> 
> 
> It all depends on the particular implementation of the socket library and
> how Ada tasks are mapped to system threads and processes. All sorts of
> resource leaks are thinkable. For example, you might be unable to listen
> that TCP/IP port until process restart or it won't abort etc.

When I decided to rework the DTraq socket interface to better handle 
disconnects, loss of comms, response timeouts, and application shutdown 
(and optimize its performance), I tried various approaches that included 
shutting down the socket from a different task and aborting the task 
that was listening on the socket.  As the socket connection was for 
asynchronous communications, I could end up trying to break (or 
experiencing a break in) the connection while it was idling, or while it 
was in the midst of data receipt or data transmission.

Most approaches worked most of the time, but I kept running into 
intermittent glitches.  When I belatedly discovered the selector support 
in GNAT.Sockets, I went with that technique, with the result being no 
more glitches, and a much cleaner implementation.

-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: Advice on abort

[Poul-Erik Andreasen]

Dmitry A. Kazakov wrote:
> On Tue, 08 Nov 2005 15:54:45 +0100, Poul-Erik Andreasen wrote:
> 
> 
>>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.
> 
> 
> It all depends on the particular implementation of the socket library and
> how Ada tasks are mapped to system threads and processes. All sorts of
> resource leaks are thinkable. For example, you might be unable to listen
> that TCP/IP port until process restart or it won't abort etc.

The time of the abortion are at the end of the first part of the
ACT so a cant se how the following could make any problems.

select
    call.foo_entry  -- this i is a guarded entry in a protected object 
or
    Abort_select
    close_socket
                  --this is the time of the abortion
then abort
    listen_to_socket  this is the function wich may be blocked
end select

-- check here if socket realy are closed;

>>>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.
> 
> 
> Not necessarily. It seems natural to decouple A) the higher level protocol
> [encapsulates a task] from B) the communication object [likely passive,
> encapsulates socket, COM port etc].
> 
>    type B is abstract new Root_Stream_Type with ... -- Abortable streams
>    procedure Abort is abstract;
> 
>    type Socket_Stream is new B with private ...;
>    type COM_Stream is new B with private ...;
> 
>    type A (Stream : access B'Class) is ...;
>    procedure Abort (X : in out A);
> private
>    type A ... record
>       Reader : Some_Task_Ptr;
>    end record;
> 
> procedure Abort (X : in out A) is
> begin
>    Abort (X.Stream); -- Aborts I/O
>    Free (Reader); -- Terminates the task
> end Abort;
> 
> With Ada 2005 interfaces one could even avoid mix-ins.

Well, instead of exporting them you import them into the task from the 
beginning. I am not saying that it is impossible to make an incapsulation.


PEA

Re: Advice on abort

[Dmitry A. Kazakov]

On Tue, 08 Nov 2005 17:59:41 +0100, Poul-Erik Andreasen wrote:

> Dmitry A. Kazakov wrote:

>> It all depends on the particular implementation of the socket library and
>> how Ada tasks are mapped to system threads and processes. All sorts of
>> resource leaks are thinkable. For example, you might be unable to listen
>> that TCP/IP port until process restart or it won't abort etc.
> 
> The time of the abortion are at the end of the first part of the
> ACT so a cant se how the following could make any problems.

Just consider a possible implementation of abort. You have a pending
operation on some hardware. Let a driver lock TCB and relevant memory pages
until I/O completion. What an Ada RTL might undertake against that, if
there is no way to cancel it, or more probably, it just does not know about
any I/O of this kind?

Consider Ada RTL scheduling Ada tasks within one system thread. In this
case any alien I/O will block everything including whole Ada RTL.

Consider ACT implementation which simply stops busy polling for I/O status
and leaves things as they are. That is: I/O continues and your task goes
further. Any consequent operation will block. Any re-opening of the same
communication channel will fail.

--------
The best solution is to use some semi-standard library. Unfortunately Ada
does not have sockets. But if we are talking about GNAT then obviously to
use GNAT.Sockets is the first candidate to consider, because ACT (no pun
intended (:-)) will hopefully take care of its reasonable implementation of
all platforms they support.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Advice on abort

[Poul-Erik Andreasen]

Dmitry A. Kazakov wrote:
> On Tue, 08 Nov 2005 17:59:41 +0100, Poul-Erik Andreasen wrote:
> 
> 
>>Dmitry A. Kazakov wrote:
> 
> 
>>>It all depends on the particular implementation of the socket library and
>>>how Ada tasks are mapped to system threads and processes. All sorts of
>>>resource leaks are thinkable. For example, you might be unable to listen
>>>that TCP/IP port until process restart or it won't abort etc.
>>
>>The time of the abortion are at the end of the first part of the
>>ACT so a cant se how the following could make any problems.
> 
> 
> Just consider a possible implementation of abort. You have a pending
> operation on some hardware. Let a driver lock TCB and relevant memory pages
> until I/O completion. What an Ada RTL might undertake against that, if
> there is no way to cancel it, or more probably, it just does not know about
> any I/O of this kind?
> 
> Consider Ada RTL scheduling Ada tasks within one system thread. In this
> case any alien I/O will block everything including whole Ada RTL.

Maybee i am a litle dump, but will these to implementation make the same
broblems whether you are inside or outside ACT

> Consider ACT implementation which simply stops busy polling for I/O status
> and leaves things as they are. That is: I/O continues and your task goes
> further. Any consequent operation will block. Any re-opening of the same
> communication channel will fail.

The ACT-feature i made deliberately for dealing with posibbly blocking
situations, and to avoiding a language-feature, on the basis of 
potentiel bad implementation, is to mee a wierd way of thinking.

> --------
> The best solution is to use some semi-standard library. Unfortunately Ada
> does not have sockets. But if we are talking about GNAT then obviously to
> use GNAT.Sockets is the first candidate to consider, because ACT (no pun
> intended (:-)) will hopefully take care of its reasonable implementation of
> all platforms they support.
> 

Quite agree

PEA

Re: Advice on abort

[Dmitry A. Kazakov]

On Wed, 09 Nov 2005 15:12:18 +0100, Poul-Erik Andreasen wrote:

> The ACT-feature i made deliberately for dealing with posibbly blocking
> situations,

It meant to deal with blocking operations as those defined by Ada standard.
Socket I/O is not covered by the language it is outside.

> and to avoiding a language-feature, on the basis of 
> potentiel bad implementation, is to mee a wierd way of thinking.

Let me put it so. Among all possible variants, abort and ACT have the
highest probability that something might get wrong. Here I don't mean buggy
compilers, I do legal ones.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Advice on abort

[Marc A. Criley]

Poul-Erik Andreasen wrote:
> Dmitry A. Kazakov wrote:
>> 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.

The way I did this was to simply wrap all the socket and selector 
interations inside a "DTraq_Stream_Handle" object, so the application is 
just interacting with it via its interface.  Yeah, the _object_ is 
accessible, but that's functionally necessary and appropriate.

-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: Advice on abort

[Poul-Erik Andreasen]

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.
>>
>>
>>PEA.
> 
> 
> I was once advised never to use ATC because it is very slow.  Is this
> true?  It was in reference to GNAT.

Not to my knowlegde, but i cant say for sure. But anything is relative, 
besides why should that bee a problem, when you call your procedure or 
entry that opens the controling guard is a very fast thing to do, and 
you wont be blocked. Any time the actual abortion take you can care less
about.

PEA.