网络程序设计-第六章.ppt

4．AfxBeginThread()函数所作的工作 当进程的主线程或其他线程调用AfxBeginThread()函数来创建一个新的用户界面线程的时候，该函数做了许多工作。 （1）它创建一个新的用户自己的线程类的对象，由于用户的线程类是从CWinThread类派生出来的，这个对象当然也继承了CWinThread类的属性。 * （2）然后，MFC就自动调用新线程类中的InitInstance()函数，来初始化这个新的线程类对象实例。这是一个必须在用户派生的线程类中重载的函数，用户可在该函数中初始化线程，并分配任何需要的动态内存。如果初始化成功，InitInstance()函数应返回TRUE，线程就可以继续运行；如果初始化失败，比如内存申请失败，就返回FALSE，线程将停止执行，并释放所拥有的资源。 （3）再调用CWinThread::CreateThread成员函数来开始执行这个线程，最终运行CWinThread::RUN函数，进入消息循环。 * （4）函数返回一个指向新生成的CWinThread对象的指针，可以把它保存在一个变量中，其它线程就可以利用这个指针来访问该线程类的成员变量或成员函数。 系统自动地为每一个线程创建一个消息队列（a message queue），如果线程创建了一个或多个窗口，就必须提供一个消息循环（a message loop），这个消息循环从线程的消息队列中获取消息，并把它们发送到相应的windows 过程（window procedures）。 * 因为系统将消息导向独立的应用程序窗口，所以，在开始线程的消息循环之前，线程必须至少创建一个窗口，大多数基于Win32的应用程序包含一个单一的线程，该线程创建了若干窗口。一个典型的应用为它的主窗口注册了窗口类，创建并显示这个主窗口，并且启动它的消息循环，所有这一切都在WinMain函数中。 * 6.3.4 终止线程 1．正常终止线程 2．提前终止线程 3．终止线程的另一种方法 4．获取线程的终止代码 5．关于设置线程的优先级问题 * * 第6章 Winsock的多线程编程 WinSock为什么需要多线程编程 6.1 Win32操作系统下的多进程多线程机制 6.2 VC++ 6.0对多线程网络编程的支持 6.3 6.1.1 WinSock的两种输入输出模式 “阻塞”模式，又称为同步模式，执行I/O操作完成前会一直进行等待，不会将控制权交给程序，工作在“阻塞”模式的套接字称为阻塞套接字。 套接字默认为阻塞模式。 可以通过多线程技术进行处理。 “非阻塞”模式，又称为异步模式，执行I/O操作时，Winsock函数会返回并交出控制权。工作在“非阻塞”模式下的套接字称为非阻塞套接字。 使用 起来比较复杂，因为函数在没有运行完成就进行返回，会不断地返回WSAEWOULDBLOCK错误，但功能强大。 * WinSock为什么需要多线程编程 6.1 * 在大多数情况下，非阻塞模式调用都会失败，返回一个WSAEWOULDBLOCK错误，表示操作的条件尚不具备，但又不允许等待完成请求的操作。 非阻塞模式下会频繁返回错误，应仔细检查返回代码；并且在不成功的情况下 不应反复轮询. “非阻塞”模式 6.1.2 两种模式的优缺点及解决方法 “阻塞”与“非阻塞”模式各有其优点和缺点。 阻塞套接字的I/O操作工作情况比较确定，无非是调用、等待、返回。大部分情况下，I/O操作都能成功地完成，不过就是花费了等待的时间 因而比较容易使用，容易编程； 但在应付诸如需要建立多个套接字连接来为多个客户服务的时候，或在数据的收发量不均匀的时候，或在输入输出的时间不确定的时候，却显得性能低下，甚至无能为力。 * 使用非阻塞套接字，需要编写更多的代码，因为必须恰当地把握调用I/O函数的时机，尽量减少无功而返的调用，还必须详加分析每个Winsock调用中收到的WSAEWOULDBLOCK错误，采取相应的对策。 这种I/O操作的随机性使得非阻塞套接字显得难于操作。 ?所以，我们必须采取一些适当的对策，克服这两种模式的缺点，让阻塞和非阻塞套接字能够满足各种场合的要求。 对于非阻塞的套接字工作模式，进一步引入了五种“套接字I/O模型”。 对于阻塞的套接字工作模式，则进一步引入了多线程机制。 * 6.2.1 Win32 OS是单用户多任务的操作系统 最早的DOS是单用户单任务的。 后来发展到图形界面的Windows，发展到Windows 95，Windows 98，就都支持多任务了。 从Windows NT起，Windows操作系统更是发展成了一个真正的抢占式多任务操作系统。 一个运行中的应用进程实例，就是一个进程。 一个基于Win32的应用