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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: open a file non-blocking ?
Date: Mon, 26 Feb 2018 10:33:47 +0100
Organization: Aioe.org NNTP Server
Message-ID: <p70k9q$g8i$1@gioia.aioe.org>
References: <6c0d9514-97e0-4c5e-9b7d-b247c2ca0ced@googlegroups.com>
 <ccc5626a-784f-4fb5-81ec-033ebd9db7d2@googlegroups.com>
NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
X-Notice: Filtered by postfilter v. 0.8.3
Content-Language: en-US
Xref: reader02.eternal-september.org comp.lang.ada:50649
Date: 2018-02-26T10:33:47+01:00
List-Id: <comp.lang.ada>

On 26/02/2018 03:53, Robert Eachus wrote:

> There is a lot of literature on non-blocking I/O which trys to minimize semaphores and mutexes.  That is more about algorithms that avoid or minimize fence instructions (SFENCE, MFENCE, and WFENCE) when you are trying to get task synchronization above a few hundred million times a second.  The easier, practical approach is to allow all of the queued actions in one thread to occur before it gives up the lock.  There may be real-time limits so that only 30 or whatever number can go through.  (Think of a traffic light used to merge lanes of traffic.  You don't want the delay too long, for when the intersection isn't busy, but you also don't want the delay too short.  This is practice syncronization protocols without fence instructions are academic theory.)
> 
> There is no way you can require an Ada library to avoid some blocking (my favorite example is a printer that runs out of paper).  Do you want that to be a blocking event?  What about spinning down a disk drive for whatever reason?

True, but I think the question was not about completely avoiding 
blocking, rather about having I/O asynchronous. Ada has a higher-level 
mechanism of timed entry call. Why not to use it for a library interface?

    select
       File.Queue_Write (Data, Write_Request);
    or delay 0.1;
       raise Device_Busy_Error;
    end select;
    ...
    select
       File.Wait_Write (Write_Request);
    or delay 1.0;
       raise Device_Timeout_Error;
    end select;

There are issues with having such interfaces. One is that protected 
types are not proper tagged types. Another is that there is no multiple 
entry calls. Normally you would want to wait for a combination of I/O 
events + termination event + timeout.

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