Re: RFC: Prototype for a user threading library in Ada

[rieachus@comcast.net]

On Saturday, June 25, 2016 at 2:29:12 AM UTC-4, Dmitry A. Kazakov wrote:
> On 2016-06-24 02:38, rieachus@comcast.net wrote:
>
> It is not a detail. The caller of Write does not know how much data the 
> transport layer is ready to accept. That is the nature of non-blocking 
> I/O. Write takes as much data it can and tells through Last where the 
> caller must continue *later*...

Thanks for the correction.  I'm used to doing that with an asynchronous pipe abstraction managed as an array of buffers.  (In Ada it would be a protected object with Put, Get and Free operations.)  The Put fills a buffer--a pointer to data and a size rather than copying anything.  The Get is called from the disk manager, which may be one of a number of storage managers, but in any case is on  different hardware.  These calls can copy all the descriptors, and Free calls can free multiple buffers.  Once you have this mechanism coded or included in your massively parallel application, tuning is needed to choose the number of buffers and how often the storage manager comes by to collect output.  You can do this truly asynchronously, but pushing large amounts of data into the MPI fabric is considered bad form--pulling is much more efficient.