LF的paper里的一处问题, 你们怎么看?

linux_c_py_php

1. class LF_Event_Handler : public Event_Handler {
   
2. private:
   
3. // This use of <Event_Handler> plays the
   
4. // <ConcreteComponent> role in the Decorator
   
5. // pattern, which is used to implement
   
6. // the application-specific functionality.
   
7. Event_Handler *concrete_event_handler_;
   
8. // Instance of an <LF_Thread_Pool>.
   
9. LF_Thread_Pool *thread_pool_;
   
10. public:
    
11. LF_Event_Handler (Event_Handler *eh,
    
12. LF_Thread_Pool *tp)
    
13. : concrete_event_handler_ (eh),
    
14. thread_pool_ (tp) {}
    
15. virtual int handle_event (HANDLE h, Event_Type et) {
    
16. // Temporarily deactivate the handler in the
    
17. // reactor to prevent race conditions.
    
18. thread_pool_->deactivate_handle (h, et);
    
19. // Promote a follower thread to become leader.
    
20. thread_pool_->promote_new_leader ();
    
21. // Dispatch application-specific event
    
22. // processing code.
    
23. concrete_event_handler_->handle_event (h, et);
    
24. // Reactivate the handle in the reactor.
    
25. thread_pool_->reactivate_handle (h, et);
    
26. }
    
27. };

复制代码

18页.

语境就是leader做I/O复用检测到某个fd的event, 然后先从fdset里去掉该fd, 然后让出leader, 然后handle_event处理这个fd发生的event, 最后reactivate_handle恢复这个fd的监听到fdset.

我注意到最后一步把fd重新加入fdset是无锁进行的, 此刻可能有另一个线程已经成为leader并处于epoll, 这样加入有可能吗?

linux_c_py_php

或者说reactivate_handle内部又走了一个pipe+queue的事件到epoll用于异步恢复fd?

windoze

在demultiplexer里加入新的event source一直是这些模型里最复杂的一个步骤。
为了安全和兼容性起见，一般会中断当前阻塞的demultiplexer，更新event source set，然后继续之前阻塞的等待操作。
Solaris里的event port好像是可以异步更新的，别的不太确定，epoll貌似是不可以，详情得查手册

linux_c_py_php

看样的确如此, 走个pipe事件绕回去好了, 也想不出什么别的路子了.

windoze

对啊，libevent神马的就是这么做的

windoze

反观Proactor模型就没有这个问题，它根本就不需要demultiplexer