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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8ddc02527645a844 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-04-01 00:42:33 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: tasking with GNAT 3.14p on windows Date: Tue, 01 Apr 2003 10:42:32 +0200 Message-ID: <67ji8vc635q6auji66pn5ugpu0q1od4lkr@4ax.com> References: <3e87f4e2$1@epflnews.epfl.ch> <7vu1djubmk.fsf@vlinux.voxelvision.no> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 1049186552 3759197 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:35851 Date: 2003-04-01T10:42:32+02:00 List-Id: On 31 Mar 2003 21:40:04 -0500, Robert A Duff wrote: >"Chad R. Meiners" writes: > >> "Jano" wrote in message >> news:MPG.18f2a01651aa20aa9896cb@News.CIS.DFN.DE... >> > trying to know the behavior with blocking I/O. In XP with -gnatP, you >> > get indefinite wait for user input, but if more than 10 seconds has >> > passed when you hit enter, you get also the "aborted" print. >> > >> > Is that expected behavior? Gnat docs say that polling implements calls >> > in each loop iteration / function call. Should I assume that if you >> > haven't loops / calls, abort will never work properly? >> >> It seems like reasonable behavior. System calls are not guaranteed to be >> abortable. > >The Ada RM has nothing to say about system calls, so of course they are >not guaranteed (by the RM) to be abortable. But I'm very interested in >what GNAT does with system calls in the presence of abort. Can you tell >us what happens if, say, a socket read is aborted? And if it's not >abortable, how does one work around that fact? The single solution I know is to close the socket from another task. This causes the pending operation to complete with an error so that the reader task might then accept a rendezous. But this is of course not an asynchronous control transfer. If sockets some time will be included into the standard library, then RM should require that all blocking socket operations be abortable and in a bounded time. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de