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,c58b7bd180ea81b2
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!194.25.134.126.MISMATCH!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Problems with Ada.Streams.Read (blocking)
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.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: <g7hher$mtt$1@aioe.org>
 <1c7gwe0hi3ew5$.1c9zms1qkzjel.dlg@40tude.net> <g7i1kc$ujv$1@aioe.org>
Date: Fri, 8 Aug 2008 20:51:01 +0200
Message-ID: <150pczbbk7gb2$.1ashrop4xh1b.dlg@40tude.net>
NNTP-Posting-Date: 08 Aug 2008 20:51:02 CEST
NNTP-Posting-Host: 080be3cf.newsspool3.arcor-online.net
X-Trace: 
 DXC=MAj2\E6]eXSE47KDAk81NWMcF=Q^Z^V3X4Fo<]lROoRQ4nDHegD_]RUfgmd^[B9GiQ[6LHn;2LCV^[<mhadbfdU[]a9khB1ff[WJDEM:QYdXj\
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:1563
Date: 2008-08-08T20:51:02+02:00
List-Id: <comp.lang.ada>

On Fri, 08 Aug 2008 20:00:44 +0200, Dennis Hoppe wrote:

> Actually, some invocation of Ada.Streams.Read (Channel.all, Buffer, 
> Index) should lead to
> 
>    Index < Buffer'Last
> 
> if the end of the stream is reached.

You never reach the end of a TCP/IP stream unless the client closes the
socket, which is usually indicates an error.

The point is that you should never care about the stream end.

> I am now able to read line per line sent by the ftp server, but if
> I only once invoke my read method to often, the whole program hangs up
> due to the blocking behavior of Ada.Stream.Read.

No, it does because you incorrectly implement the protocol. Typically, you
send a request to the server and it answers with a chain of records. The
number and the content of the records is determined by the protocol. So you
can always know what to expect. Pseudo-code looks like

   -- Processing a request
   send request
   loop
      read one record
      interpret the content of
      exit when no records should follow
   end loop
   -- Ready to issue another request
   ...

You have mentioned FTP. There is a clear definition of how a FTP server
response ends:

"The client can identify the last line of the response as follows: it
begins with three ASCII digits and a space; previous lines do not. The
three digits form a code. Codes between 100 and 199 indicate marks; codes
between 200 and 399 indicate acceptance; codes between 400 and 599 indicate
rejection."
  --  http://cr.yp.to/ftp/request.html

If you correctly implement the protocol your application will never block
unless the server is not busy. And you have to read out all response
otherwise the server will be block. So both parties know the states of each
other.

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