QNX之编写资源管理器（八）
QNX相关历史文章：
Unblocking Clients and Handling Interrupts
这篇文章主要描述资源管理器对客户端的解阻塞，以及中断的处理。
1. Handling client unblocking due to signals or timeouts
资源管理器提供的另一个方便的服务就是解除阻塞。
当一个客户端发起请求，比如调用read()，会转变成MsgSend()向资源管理器发送消息，这是一个阻塞调用。如果客户端在MsgSend()未完成期间收到一个信号，资源管理器需要给出一些指示，以便它可以中止请求。
因为库在调用ChannelCreate()时设置了_NTO_CHF_UNBLOCK标志，所以当客户端试图从MsgSend()(并且已经通过MsgReceive()收到消息)中解除阻塞时，都会收到一个脉冲。之前也讲过当客户端发送消息给资源管理器时，可能处在两种阻塞状态：
-
SEND-blocked，此时资源管理器还没收到； -
REPLY-blocked，此时资源管理器还没有调用MsgReply()回复；
当产生脉冲时，资源管理器库会处理这个脉冲消息，并合成一个_IO_UNBLOCK消息。
在resmgr_io_funcs_t和resmgr_connect_funcs_t结构体中，有两个unblock message的处理函数：一个在I/O函数中，一个在连接函数中。有两个处理函数的原因是因为可能在上边这两种情况中中止。
一旦执行了_IO_CONNECT消息的处理，I/O函数中的unblock成员将用于处理unblock pulse。因此在提供自己的io_open处理程序时，先确保在调用resmgr_open_bind()之前设置好了OCB中所有相关字段，否则I/O函数中的unblock处理程序调用时可能会用到OCB中无效数据。（注意，只有在资源管理器中有多个线程在运行时，才会出现消息处理期间脉冲中止的问题，如果只有一个线程，那么消息将由库的MsgReceive()函数序列化）
当客户端处于SEND-blocked状态时，服务器不需要知道用户正在中止请求，因为它还没收到消息。只有收到后并对该请求执行处理的情况下，才需要知道客户端的中止需求。
如果要覆盖默认的unblock处理函数iofunc_unblock_default()，应该首先调用这个默认的处理函数，保证能处理通用的情况。这可以确保在资源管理器列表中的客户端能被解阻塞，需要一些方法来遍历阻塞的客户端rcvid表，找到匹配的然后进行阻塞解除。
例程应该通过调用MsgInfo()检查_NTO_MI_UNBLOCK_REQ标志来确认unblock仍然处于挂起状态（避免出现竞争条件）。如果找不到匹配的客户端，可以通过返回_RESMGR_NOREPLY来忽略unblock请求。
/* Check if rcvid is still valid and still has an unblock
request pending. */
if (MsgInfo(ctp->rcvid, &info) == -1 ||
!(info.flags & _NTO_MI_UNBLOCK_REQ)) {
return _RESMGR_NOREPLY;
}
如果没有提供unblock处理程序，可以让客户端处在REPLY-blocked状态，当客户端终止时，服务器必须有机会来清理客户端数据结构。
2. Unblocking if someone closes a file descriptor
假设有以下情况：
- 客户端中一个线程打开文件描述符，并调用
read()函数； - 资源管理器在
io_read处理函数中没有回复，客户端处于阻塞状态； - 客户端中的另一个线程关闭同一个文件描述符；
如果资源管理器不处理这种情况，则第一个线程会无限阻塞在read()操作中。在其他阻塞操作中，比如write()、devctl()等中也可能出现这种情况。
为了避免这种情况出现，资源管理器需要为阻塞的客户端维护一个列表，当有客户端阻塞时便添加到该列表中，解除阻塞时则移除。
在执行close()时，会调用资源管理器框架提供的io_close_dup()的处理函数，在这个io_close_dup()函数中，应该遍历列表，并根据server connection ID (scoid)和connection ID (coid)来定位哪个客户端阻塞在该文件描述符上，并对它们进行回复以便解除阻塞。比如：
int io_close_dup (resmgr_context_t *ctp, io_close_t *msg, RESMGR_OCB_T *ocb)
{
// unblock any clients blocked on the file descriptor being closed
blocked_client_t *client, *prev;
prev = NULL;
client = blocked_clients;
while ( client != NULL )
{
if ( (client->coid == ctp->info.coid) && (client->scoid == ctp->info.scoid) )
{
MsgError( client -> rcvid, EBADF );
if (prev != NULL) // anywhere but the head of the list
{
prev->next = client->next;
free(client);
client = prev->next;
}
else // head of the list case
{
blocked_clients = client->next;
free(client);
client = blocked_clients;
}
}
else // no match, move to the next entry and track previous entry
{
prev = client;
client = client->next;
}
}
// do rest of the regular close handling
return iofunc_close_dup_default(ctp, msg, ocb );
}
3. Handling interrupts
管理硬件的资源管理器需要处理硬件的中断。当中断处理函数中发生了重要事件时，处理程序需要通知资源管理器的线程，这通常通过一个脉冲来完成，也可以使用SIGEV_INTR事件通知类型来完成。
当资源管理器启动时，它将控制权转交给thread_pool_start()，这个函数可能返回，也可能不返回，这个取决于传递给thread_pool_create()的标志（如果没有传递标志，函数在创建线程池之后返回）。这意味着需要在启动线程池之前进行设置。
如果使用SIGEV_INTR事件通知类型，就会遇到一个问题，那就是连接中断的线程（通过InterruptAttach()或InterruptAttachEvent()）必须与调用InterruptWait()的线程是同一个。
下边是一个关于中断的示例代码：
#define INTNUM 0
#include <stdio.h>
#include <stddef.h>
#include <stdlib.h>
#include <sys/iofunc.h>
#include <sys/dispatch.h>
#include <sys/neutrino.h>
static resmgr_connect_funcs_t connect_funcs;
static resmgr_io_funcs_t io_funcs;
static iofunc_attr_t attr;
void *
interrupt_thread (void * data)
{
struct sigevent event;
int id;
/* fill in "event" structure */
memset(&event, 0, sizeof(event));
event.sigev_notify = SIGEV_INTR;
/* Obtain I/O privileges */
ThreadCtl( _NTO_TCTL_IO, 0 );
/* intNum is the desired interrupt level */
id = InterruptAttachEvent (INTNUM, &event, 0);
/*... insert your code here ... */
while (1) {
InterruptWait (NULL, NULL);
/* do something about the interrupt,
* perhaps updating some shared
* structures in the resource manager
*
* unmask the interrupt when done
*/
InterruptUnmask(INTNUM, id);
}
}
int
main(int argc, char **argv) {
thread_pool_attr_t pool_attr;
resmgr_attr_t resmgr_attr;
dispatch_t *dpp;
thread_pool_t *tpp;
int id;
if((dpp = dispatch_create()) == NULL) {
fprintf(stderr,
"%s: Unable to allocate dispatch handle.\n",
argv[0]);
return EXIT_FAILURE;
}
memset(&pool_attr, 0, sizeof pool_attr);
pool_attr.handle = dpp;
pool_attr.context_alloc = dispatch_context_alloc;
pool_attr.block_func = dispatch_block;
pool_attr.unblock_func = dispatch_unblock;
pool_attr.handler_func = dispatch_handler;
pool_attr.context_free = dispatch_context_free;
pool_attr.lo_water = 2;
pool_attr.hi_water = 4;
pool_attr.increment = 1;
pool_attr.maximum = 50;
if((tpp = thread_pool_create(&pool_attr,
POOL_FLAG_EXIT_SELF)) == NULL) {
fprintf(stderr, "%s: Unable to initialize thread pool.\n",
argv[0]);
return EXIT_FAILURE;
}
iofunc_func_init(_RESMGR_CONNECT_NFUNCS, &connect_funcs,
_RESMGR_IO_NFUNCS, &io_funcs);
iofunc_attr_init(&attr, S_IFNAM | 0666, 0, 0);
memset(&resmgr_attr, 0, sizeof resmgr_attr);
resmgr_attr.nparts_max = 1;
resmgr_attr.msg_max_size = 2048;
if((id = resmgr_attach(dpp, &resmgr_attr, "/dev/sample",
_FTYPE_ANY, 0,
&connect_funcs, &io_funcs, &attr)) == -1) {
fprintf(stderr, "%s: Unable to attach name.\n", argv[0]);
return EXIT_FAILURE;
}
/* Start the thread that will handle interrupt events. */
pthread_create (NULL, NULL, interrupt_thread, NULL);
/* Never returns */
thread_pool_start(tpp);
}
这里的interrupt_thread()函数使用了InterruptAttachEvent()将中断源(intNum)绑定到事件上，然后等待事件的发生。
这个方法相对于使用脉冲有一个优势，脉冲作为消息传递给资源管理器，意味着如果资源管理器的消息处理线程正在忙着处理请求，那么这个脉冲就需要排队，直到一个线程执行MsgReceive()。使用InterruptWait()方法，如果执行InterruptWait()的线程具有足够的优先级，那么它在生成SIGEV_INTR之后立即解除阻塞并运行。
