Page 182 - DCAP507_SYSTEM_SOFTWARE

System Software

Notes Unless otherwise observed, when the behaviour of an asynchronous operation is defined "as if"
executed by a POSIX function, the handler will be invoked with a value of type error_code that
matches to the failure condition depicted by POSIX for that function, if any. Or else the handler
will be invoked with an implementation-defined error_code value that reflects the operating
system error.
Asynchronous operations will not stop working with an error condition that signifies interruption
by a signal (POSIX EINTR). Asynchronous operations will not fail with any error condition
connected with non-blocking operations (POSIX EWOULDBLOCK, EAGAIN or EINPROGRESS;
Windows WSAEWOULDBLOCK or WSAEINPROGRESS).

All asynchronous operations have an connected io_service object. Where the starting function is
a member function, the connected io_service is that returned by the io_service() member function
on the same object. Where the starting function is not a member function, the related io_service
is that returned by theio_service() member function of the first argument to the starting function.
Arguments to starting functions will be considered as follows:

 If the parameter is stated as a const reference or by-value, the program is not needed to
confirm the validity of the argument after the initiating function finishes. The execution
may make copies of the argument, and all copies will be destroyed no later than instantly
after invocation of the handler.
 If the parameter is stated as a non-const reference, const pointer or non-const pointer, the
program must confirm the validity of the argument until the handler is invoked.
The library implementation is only allowed to make calls to an initiating function's arguments'
copy constructors or destructors from a thread that fulfills one of the following conditions:
 The thread is implementing any member function of the related io_service object.
 The thread is implementing the destructor of the related io_service object.
 The thread is implementing one of the io_service service access functions use_service,
add_service or has_service, where the first argument is the associated io_service object.
 The thread is implementing any member function, constructor or destructor of an object
of a class defined in this clause, where the object's io_service() member function returns
the associated io_service object.

 The thread is implementing any function defined in this clause, where any argument to the
function has an io_service() member function that returns the associatedio_service object.
The above needs are proposed to avert these hidden threads from making calls to program code.
This indicates that a program can, for instance, use thread-unsafe reference counting in handler
objects, provided the program makes sure that all calls to an io_service and associated objects
take place from the one thread.
The io_service object related with an asynchronous operation will have uncompleted work, as
if by sustaining the subsistence of one or more objects of classio_service::work constructed by
means of the io_service, until instantly after the handler for the asynchronous operation has
been invoked.

When an asynchronous operation is accomplished, the handler for the operation will be invoked
as if by:
1. Building a bound completion handler bch for the handler, as described below.

2. Calling ios.post(bch) to schedule the handler for delayed invocation, where ios is the
associated io_service.

176 LOVELY PROFESSIONAL UNIVERSITY