Asynchronous data transfers.

With DAGDA, there is two way to manage the asynchronous data transfers, depending of the data usage:

• With end-of-transfer control: DAGDA maintains a reference to the transfer thread. It only release this reference after a call to the corresponding waiting function. The client developer should allways use these functions, that's why a data ID is only returned by the "dagda_wait_*" and "dagda_wait_data_ID" functions.
• Without end-of-transfer control: The data is loaded from/to the DAGDA hierarchy without the possibility to wait for the end of the transfer. These functions should only be called from an agent plugin scheduler, a SeD plugin scheduler or a SeD if the data transfer without usage of the data is one of the objectives of the called service. The data adding functions without control should be used very carefully because there is no way to be sure the data transfer is achieved or even started.

With asynchronous transfers, the user should take care of the data lifetime because DAGDA does not duplicate the data pointed by the passed pointer. For example, if the program uses a local variable reference to add a data to the DAGDA hierarchy and go out of the variable scope, a crash could occured because the data pointer could be freed by the system before DAGDA has finished to read it.