8.6 Summary

Ru-Brd

This chapter explored the concept of proactive I/O and outlined how the proactive model differs from the reactive model. It also showed how the proactive I/O model can be used to overcome the performance limitations of the reactive I/O model without incurring certain liabilities associated with the use of multithreaded synchronous I/O. However, the proactive I/O model presents several challenges:

• Design challenges. The multistep nature of this model increases the likelihood of overly coupling the I/O mechanisms that initiate asynchronous operations with the processing of the completions of operations.

• Portability challenges. There are highly divergent standards and implementations for asynchronous I/O offered by today's computing platforms.

The Proactor pattern [POSA2] defines a set of roles and relationships to help simplify applications that use proactive I/O. The ACE Proactor framework implements the Proactor pattern across a range of operating systems that support asynchronous I/O. The ACE Proactor framework provides a set of classes that simplify networked application use of asynchronous I/O capabilities across all platforms that offer it. This chapter discussed each class in the framework, covering their motivations and capabilities. It showed an implementation of the client logging daemon that uses the proactive I/O model for all of its network operations. This version of the client logging daemon works portably on all ACE platforms that offer asynchronous I/O mechanisms.

Ru-Brd