On the client side , ardp_send() can be called synchronously or asynchronously, depending on the parameter ttwait . If ttwait = -1 , ardp_send() blocks. If ttwait = 0 , it returns immediately (without calling ardp_retrieve()). If ttwait > 0 , it calls ardp_retrieve() and waits for ttwait microseconds before it returns.
If ardp_send() is called asynchronously, the client application must poll the server periodically using ardp_retrieve() to check for the reply to a specific request or ardp_process_active() for replies to any requests (note that ardp_process_active() can be called by either the client and the server, and checks for both responses to client requests or new requests to the server).
The client could also specify a routine to be called to process a response to a request (upcall). In ARDP's RREQ data, the application can specify the pointer to the function to be called. The function could be called after a request is completed. Note that this still requires the client to periodically check for replies from the server. The specified function would be called at the end of ardp_process_active().
To avoid having to periodically check for replies, the client could use the signal() call to intercept SIGIOs on the client's data port, and call a signal handler to process the interrupt. The signal handler would be part of the ARDP library and would have similar functionality as ardp_process_active(). The client could still specify a pointer to a function to be executed by the signal handler when a request is completed.